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

Mališa Vučinić <malisa.vucinic@inria.fr> Thu, 28 March 2019 16:25 UTC

Return-Path: <malisa.vucinic@inria.fr>
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 6B87512008A for <6tisch@ietfa.amsl.com>; Thu, 28 Mar 2019 09:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.92
X-Spam-Level:
X-Spam-Status: No, score=-5.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 No1UBB-eSfSu for <6tisch@ietfa.amsl.com>; Thu, 28 Mar 2019 09:25:53 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28BA61202E9 for <6tisch@ietf.org>; Thu, 28 Mar 2019 09:24:48 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,280,1549926000"; d="scan'208,217";a="301067073"
Received: from wifi-pro-83-108.paris.inria.fr ([128.93.83.108]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Mar 2019 17:24:47 +0100
From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <malisa.vucinic@inria.fr>
Message-Id: <1CE26FD6-ACDB-4E95-A195-19953750FDD9@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C3522B21-C16D-4166-8B98-F66B97DC6F9D"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Thu, 28 Mar 2019 17:24:46 +0100
In-Reply-To: <20190328002907.GC28841@hephaistos.amsuess.com>
Cc: 6tisch@ietf.org
To: =?utf-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>
References: <20190327172921.GA9348@hephaistos.amsuess.com> <B7DECDC9-5521-4A0B-9590-0620CF123CA7@inria.fr> <20190328002907.GC28841@hephaistos.amsuess.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/CHgpoXzxLIc_4h5-EoUke31cuU8>
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 16:25:57 -0000

Hello Christian,

The intent was indeed to differentiate between “I cannot do what is requested with parameter X” and “I understand parameter X but not what you are asking me to do with it”. To avoid ambiguity, I now use the terms “unsupported” and “malformed” as code values.

Essentially, along the notes of your proposal I modified the text and specified two objects:

Unsupported_Configuration = [
       + parameter           : Unsupported_Parameter
]

Unsupported_Parameter = (
         code                : int,
         parameter_label     : int,
         parameter_value     : any
)

with code being either “Unsupported” or “Malformed”. In either case, parameter_label and parameter_value are returned. This structure also supports the signaling of individual link layer keys, as the "link-layer key set” parameter label can be signaled together with the subset of the original keys. 

Note that the message name carrying this response is still called Diagnostic Response message. The commit was squashed with the previous one and the diff is available at:
https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/branch/minimal-security-10?dest=minimal-security-10-goran#diff <https://bitbucket.org/6tisch/draft-ietf-6tisch-minimal-security/branch/minimal-security-10?dest=minimal-security-10-goran#diff>

Let me know what do you think.

Mališa


> On 28 Mar 2019, at 01:29, Christian Amsüss <christian@amsuess.com> wrote:
> 
> 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