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

Christian Amsüss <> Thu, 28 March 2019 00:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9316512006A for <>; Wed, 27 Mar 2019 17:29:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8CqcIiLx-rcP for <>; Wed, 27 Mar 2019 17:29:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DE7901200F4 for <>; Wed, 27 Mar 2019 17:29:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPS id D17944380B; Thu, 28 Mar 2019 01:29:09 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id 2098036; Thu, 28 Mar 2019 01:29:09 +0100 (CET)
Received: from (unknown []) by (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?= <>
To: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="pAwQNkOnpTn9IO2O"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [6tisch] draft-ietf-6tisch-minimal-security: Error code and server state
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" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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