Re: [core] draft-hartke-core-stateless

[Klaus Hartke <[e-mail]>]

Hi Jim,

thanks for the thorough review! I've just submitted revision -01 with some clarifications.

> 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.

Could you give an example? To me it seems that a message format error or unsupported critical unsafe-to-forward option will reliably give a Reset message or Bad Option response from the next hop.

> 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.

This is a very good question and a point that needs discussion in the WG. We could mandate a fixed upper limit that all implementations of the draft must support, or try to come up with some maximum length token detection/negotiation.

> 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.

I'm skipping these points as Section 3/Variant B is removed in revision -01.

> 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 true 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.

Good observation. I've rephrased this part in revision -01. Could you take a look?

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

Text contributions to the draft are highly welcome :)

> Someplace - Interactions between OSCORE and this new option.

I don't think there are any interactions with OSCORE.

> 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.

Text contributions to the draft are highly welcome :)

Klaus