[core] draft-hartke-core-stateless

[Jim Schaad <[e-mail]>]

Section 2.2.2 - Depending on circumstances, I think you might get a Gateway
time out error response as well for some types of proxies.

Section 2.2.2 - Should there be a special indicator that a server cannot
deal with tokens of longer than n bytes?  Otherwise this would seem to be a
good way to exhaust resources on the server/proxy.

Section 3.1 - I would think that repeatable would be better for the option
as then multiple proxies could just insert a new option rather than
attempting to extend or wrap the current value.

Section 3.1 - I am not sure that I agree that the option should be unsafe to
forward.  As long as a client and a server agree to deal with the option
then it does not matter what any intermediate proxies might do.  Changing
this modifies 3.2.2 as well

Section 3.1 - above two arguments would change the values of critical as
well.  I still think that it would be part of the cache key for a proxy that
did not understand the option, it might be noted that a proxy which
understands the option would be in its right to exclude the option from
computing the cache key.

Section 3.1 - The last sentence may need to have some additional text added
about the length of the Token field when splitting the value.  Also needs to
have a note about the interactions messages in those cases where the portion
placed in the token field does not change.  This seems quite possible if one
uses a prefix.

Section 4 - What happens for interactions w/ the observe option?

Section 4.1 - I don't see how paragraph 3 follows from the use of this
option.  This is merely a tree statement for all intermediaries that don't
bother caching.  Note that if the intermediary does cache responses, but
does not cache this option then the entire paragraph does not seem to be
correct.  It could respond from the cache, but not worry about keeping this
value in the cache and trying to figure out when and how to ignore.

Security Considerations - Need additional text someplace about swapping of
tokens which might be more consequential than would normally be the case.

Someplace - Interactions between OSCORE and this new option.

Freshness indicator may need to be dealt with on a per server basis or using
the same type of window that DTLS uses.  If a client sends out two different
messages to two different servers, the order of responses should not control
if a response is processed.

Jim