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

Mališa Vučinić <> Wed, 27 March 2019 22:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6958912001E for <>; Wed, 27 Mar 2019 15:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.92
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bVSPo1HZ3JRi for <>; Wed, 27 Mar 2019 15:29:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DA8E120091 for <>; Wed, 27 Mar 2019 15:29:23 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.60,277,1549926000"; d="scan'208,217";a="300956712"
Received: from (HELO mp341-pro.home) ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Mar 2019 23:29:02 +0100
From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9D6CFA8B-1208-42C0-9E85-67CE3035F2D0"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 27 Mar 2019 23:29:01 +0100
In-Reply-To: <>
To: =?utf-8?Q?Christian_Ams=C3=BCss?= <>
References: <>
X-Mailer: Apple Mail (2.3445.102.3)
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: Wed, 27 Mar 2019 22:29:46 -0000

Hello Christian,

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:
- encoding additional info as a CBOR array allowing multiple parameters to be transported within
- removing the previous error code which explicitly was referring to the state of a request
- renaming of Error object to Diagnostic, if you have a better naming proposal, please let me know
- encapsulating the entire link layer key object(s) that is unsupported by a given pledge. I believe this is the simplest handling from the pledge implementation point of view as it can simply memcpy the byte string received

I also did some minor edits to align the text in the rest of the document, the related diff is available at: <>

Please let me know if you see any issue with this resolution.


> On 27 Mar 2019, at 18:29, Christian Amsüss <> wrote:
> Hello Mališa,
> we've just talked about server state and the error codes sent with
> subsequent join requests in [1], especially Sections 8.4.1 and Section
> 8.4.5. (Working group, please be aware that I have not read and
> understood the full document but am responding to a particular question
> here).
> My understanding is that the pledge POSTs its Join_Request to the
> server, initially without an Error, and receives a response. If it has
> trouble acting on the response, it sends another request that includes
> the original parameters plus an error object; the server may respond to
> that with a more final error ("Sorry, then I can't help you either") or
> by sending a different response ("OK, if you can't do X, here's a setup
> that works without that"). The question is as whether that agrees with
> the a RESTful design and to the stateless servers we aspire in CoRE.
> The error handling as currently described requires the server to keep
> around information about the previous request. That is not per se a
> violation of the side effect rules of CoAP (as the request is a POST and
> the server may change state as a result), but has non-idempotent POST
> requests which are discouraged in CoRE, and could be avoided easily.
> Suggestion: Chain errors in the requests
> ----------------------------------------
> I suggest that only errors be sent in subsequent requests that are
> self-descriptive, and not so much indicate "what happened" but more
> "what the pledge can't do"; then the server does not need to remember
> the history of each pledge's requests.
> If that is to be played back-and-forth (and I understand there are up to
> four attempts), this requires that the pledge can indicate more than one
> thing that went wrong. As long as there is only one error field, if
> (say) the client tells the server after the first round-trip that it
> doesn't support option X and the server offers option Y instead, the
> client could only indicate with the response that it won't support
> option Y, and the server would happily give it X again. Making the error
> field in the Join_Request a list would ease that, and might even allow
> for fewer round-trips if the pledge can issue complaints about several
> options in the first round-trip.
> Having a list of errors does obviously increase complexity a little, and
> it requires the client to keep track of things that it dislikes about
> the server's previous responses. My impression is that pledges can
> probably afford that (it's state of size that's limited by the number of
> attempts it's willing to do, and is only kept during the joining
> process), freeing the serve of keeping around state of every pledge for
> some potentially-hard-to-tell time.
> Suggestion: Require errors to be self-descriptive
> -------------------------------------------------
> With that alone, a stateless server can be constructed, though the
> conceptualization would be a bit convoluted (the precise rules of
> interpreting the error codes would be "Had I sent you this request with
> one less error, your response would trigger error X in me") --
> stateless, but not particularly elegant to think about or easy to act
> on.
> If the error codes could be limited to statements that are valid truths
> irrespective of hypothetical answers, that would look cleaner but
> supports only error codes that state such valid truths. Conceptually, it
> would not so much be an "error" field but a "things I'm telling you in
> advance I can't do".
> Of the list in Table 4, I'd say that
> * 0 is not applicable (it's a server response)
> * 1 should not be expected to be recoverable, and in this model of
>  thought becomes very fuzzy. ("Give me that, but I know I can't act on
>  it...?")
> * 2 is fine as long as it relates to the number of the option it doesn't
>  understand but not the value (The statement would be "I don't support
>  option X" -- something the pledge could have even said in advance).
> * 3 is not good but can easily be fixed by indicating a key ID rather
>  than an index in a list whose indices will change when the server
>  tries to do better.
> * 4 is fine (that, like with 2, is something the pledge could even have
>  said in advance).
> From the discussion before I take it that this is something that can
> easily be fixed; if you want me to look at the changes you'd make to
> accommodate this, I'd be happy to have a brief look. (Just please CC me,
> I'm not actively reading the 6tisch list).
> Have a good flight
> Christian
> [1]:
> -- 
> To use raw power is to make yourself infinitely vulnerable to greater powers.
>  -- Bene Gesserit axiom