Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)
draft-ietf-core-stateless-08

** I support Ben Kaduk’s DISCUSS position that the SHOULDs in Section 3.1 would likely be better described as MUSTs.  Additionally, I would recommend, threading this guidance with Section 3.3. and 5.2.  Specifically:

-- Section 3.3.  Per “If a piggybacked response passes the token integrity protection and freshness checks …” and “If a separate response passes the token integrity protection and freshness checks …”, where is the guidance for these checks described?  Is that the language in Section 3.1?

-- Section 5.2.  Per “The use of encryption, integrity protection, and replay protection of serialized state is recommended …”, why not “RECOMMENDED”?  How does this text line with the conditions outlined in Section 3.1?

-- Section 5.2.  Per “AES-CCM  with a 64 bit tag is recommended …”, why not “RECOMMENDED?”

** Section 5.2.  Please provide a citation for AES-CCM and HMAC-SHA-256.

** Section 5.2. Recommend describing the consequences of not using security services.  Perhaps something on the order of:

OLD:
   The use of encryption, integrity protection, and replay protection of
   serialized state is recommended , unless a careful analysis of any
   potential attacks to security and privacy is performed.  

NEW
The use of encryption, integrity protection, and replay protection of serialized state is recommended, unless a careful analysis of any potential attacks to security and privacy is performed.  In the absence of integrity and reply protection, an on-path attacker or rogue server/intermediary could return a state (either one modified in a reply, or an unsolicited one) that could alter the internal state of the client stack.

** Editorial nit:
-- Figure 2 and 5.  I would recommend replacing the colloquialism “look ma, no state!” with “no state”.

Thank you for this, it was a pleasant and easy read (especially as I am not a COAP person). 

1: I'd believe that the Abstract needs to say *how* "This document updates RFCs 7252 and 8323." (A simple copy and paste from the start of Section 2 would satisfy this)

2: This is not actionable, but I really really enjoyed the "look ma, no state!" bit in Figure 2.

Thank you for keeping documents interesting and fun to read...

Thank you for the work put into this document. The document is clear, easy to read and quite useful. The security aspects are also well defined.

Please find below a single non-blocking COMMENT. An answer will be appreciated.

I hope that this helps to improve the document,

Regards,

-éric

-- Section 2.1 --
Why does this document update RFC 8323 definition of TKL? At first sight, the TKL field definitions in this document and in RFC 8323 look identical.

Thank you for addressing my Discuss (and Comment!) points.

Like everyone else, I enjoyed reading this. But could we paginate the document?

Thanks for this document.  I found the document easy to read and the concept described easy to understand.

A few minor comments:


2.1 Extended Token Length (TKL) Field

      13:  An 8-bit unsigned integer precedes the Token field and
         indicates the length of the Token field minus 13.

      14:  A 16-bit unsigned integer in network byte order precedes the
         Token field and indicates the length of the Token field minus
         269.
         
I wonder whether it would be worth changing "precedes" to "directly precedes" to avoid any doubt of exactly where the length field appears?  Although I note that the updated message formats are in the appendix anyway.


2.2.1.  Extended-Token-Length Capability Option

 The draft doesn't suggest whether the Extended-Token-Length capability option should be used when the server only supports a max-length of 8.  Would it be useful to give a recommendation for servers in this case, e.g.  SHOULD they only include the capability if they support a max token length larger than 8 bytes?

 
3.  Stateless Clients

   As servers are just expected to return any token verbatim to the
   client, this implementation strategy for clients does impact the
   interoperability of client and server implementations.  However,
   there are a number of significant, non-obvious implications (e.g.,
   related to security and other CoAP protocol features) that client
   implementations need take into consideration.
   
I found the first sentence somewhat unclear - in that I was wondering if "does not impact" was intended instead of "does impact"?  Or otherwise, I wasn't quite sure what this sentence was trying to convey.