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

[Mališa Vučinić <[e-mail]>]

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 <[e-mail]> 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