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

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

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:
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>

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

Mališa

> On 27 Mar 2019, at 18:29, Christian Amsüss <[e-mail]> 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]: https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09
> 
> -- 
> To use raw power is to make yourself infinitely vulnerable to greater powers.
>  -- Bene Gesserit axiom