Re: [6tisch] draft-ietf-6tisch-minimal-security: Error code and server state

Christian Amsüss <christian@amsuess.com> Thu, 28 March 2019 00:29 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9316512006A for <6tisch@ietfa.amsl.com>; Wed, 27 Mar 2019 17:29:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
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 8CqcIiLx-rcP for <6tisch@ietfa.amsl.com>; Wed, 27 Mar 2019 17:29:12 -0700 (PDT)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE7901200F4 for <6tisch@ietf.org>; Wed, 27 Mar 2019 17:29:11 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id D17944380B; Thu, 28 Mar 2019 01:29:09 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 2098036; Thu, 28 Mar 2019 01:29:09 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [83.208.252.99]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id A9D607A; Thu, 28 Mar 2019 01:29:08 +0100 (CET)
Received: (nullmailer pid 6294 invoked by uid 1000); Thu, 28 Mar 2019 00:29:07 -0000
Date: Thu, 28 Mar 2019 01:29:07 +0100
From: Christian =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>
To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malisa.vucinic@inria.fr>
Cc: 6tisch@ietf.org
Message-ID: <20190328002907.GC28841@hephaistos.amsuess.com>
References: <20190327172921.GA9348@hephaistos.amsuess.com> <B7DECDC9-5521-4A0B-9590-0620CF123CA7@inria.fr>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pAwQNkOnpTn9IO2O"
Content-Disposition: inline
In-Reply-To: <B7DECDC9-5521-4A0B-9590-0620CF123CA7@inria.fr>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/DCigD1qJ5W_rKgNYWUUezq1_9GM>
Subject: Re: [6tisch] draft-ietf-6tisch-minimal-security: Error code and server state
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Mar 2019 00:29:15 -0000

Hello Mališa,

> Thank you for summarizing the discussion we had and proposing these changes. I have modified the text in order to reflect the email below by:

I'm not sure I understand the distinction between "unsupported" and
"unexpected" parameters. Are they about having an unknown code vs.
having an unknown value? If so, the unexpected additional info should
include the full value in the diagnostic, and not only the label.

I don't quite see how the arrays come in here, especially given that I
didn't find the Diagnostic CDDL used anywhere in the updated document
(JoinRequest still only has Error). Is the intention here that there is
only one Diagnostic, with only one code and a list of values? With that
a pledge could say that it won't understand options X and Y, but it
can't say that it won't understand option X and can't use the link-layer
key Y.

(On an editorial note, the "Additional info type" could go away in
#table_diagnostic_codes, but given the above I think they should rathe
stay uint / uint (key_id) / Configuration, and have at some point a `?
8: [ +Diagnostic ]` or so).

> - renaming of Error object to Diagnostic, if you have a better naming proposal, please let me know

I'd call it UnsupportedConfigurations, but that's really a matter of
overall document terminology which I'm unfamiliar with.

Kind regards
Christian

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