[core] Robert Wilton's No Objection on draft-ietf-core-stateless-06: (with COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-core-stateless-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-stateless/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.