Hi Klaus, Your email somehow ended up being classified as Spam by Google's filter and I found it only after explicitly searching for it in the Spam folder.
As discussed offline, we are happy in 6tisch to make this functionality useful for the general-purpose CoAP in collaboration with CoRE. Let's discuss further during 6TiSCH today and in the next days. Mališa On Fri, Jun 29, 2018 at 10:21 PM Klaus Hartke <[email protected]> wrote: > I've reviewed draft-ietf-6tisch-minimal-security-06, focusing on the parts > that involve CoAP. > > The Stateless-Proxy option is interesting. When a CoAP client (or proxy in > the role of a client) makes a request, it usually has some state > information at that point in time and requires that information to continue > where it left off when receiving the response. CoAP facilitates this by the > Token: an opaque value that is sent along the request and echoed back > verbatim in the response. > > When the Token was designed in the CoRE working group, we had a discussion > if the token value should just serve as an identifier for the state > information stored at the client, or if the client should be enabled to > encode information directly in the token, protected by an authentication > tag, which would allow the client to continue where it left off without > keeping any state information in the meantime. Since we didn't have a > specific use case at that time, the (non-reversible) decision was made to > not allow it and to limit the token value to a maximum size of 8 bytes. > > The Stateless-Proxy option overturns that decision. While I think that the > original decision was not the best, this is really unfortunate. Not only > are there are now two tokens in a message, which doesn't help with keeping > the protocol simple and easy to understand; the new token is also not even > always echoed back. > > I don't see why a protocol extension is needed in the first place. It > seems the current functionality could be achieved equally as well by > passing the state information in the payload [1]. > > Seeing that Tero also has some comments on statelessness, I think that > this part needs more work. > > The other parts involving CoAP look good to me. (The prescribed URI path > "j" is a bit suspicious since it conflicts with BCP 190, but might be fine > because of the "6tisch.arpa" authority.) > > Klaus > > [1] E.g.: JP receives request from pledge, wraps that request and state > information in a new payload, makes request with that payload to JRC, > receives a response from JRC, unwraps response to pledge and state > information from response from JRC, sends response to pledge. > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
