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

[Christian Amsüss <[e-mail]>]

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