Re: [core] 🔔 WGLC of draft-ietf-core-stateless-01

[Klaus Hartke <[e-mail]>]

Carsten Bormann wrote:
> # Major
>
> Discovery is currently focused on whether the server supports extended token lengths at all.  Given that the maximum extended token is rather large for a constrained environment, the client may be interested to find out how large tokens can be for this server.  With CSM, this would be trivial (change empty option value to an uint value).  With trial-and-error, this leaves the client with binary search (probably along the lines of the token sizes it actually can make use of).

As discussed in the CoRE virtual interim, it's probably safe to assume
that a client in a constrained environment is already choosing the
most compact token possible for the task. So there's probably not much
it could do when it learns that the server supports extended token
lengths but not of that length (other than, e.g., as a stateless
client going back to making stateful requests).

Changing the CSM from empty to uint might still be worth doing,
though. Done in -02.

> # Minor
>
> Section 3.3 suddenly starts to talk about authentication tags and freshness indicators; this might require additional explanation (in particular since there are BCP 14 keywords in these paragraphs).  Section 4.2.1 has some implementation guidelines that could possibly be expanded to cover this.

I'll move the requirements from section 4.2 to section 3 in -02 to
provide better context.

Thanks!

Klaus