[core] Chairs' review of draft-ietf-core-stateless-03.txt

[Carsten Bormann <[e-mail]>]

I did a review of draft-ietf-core-stateless-03.txt, with non-trivial results below.
(Editorial nits went directly to the author.)

I haven’t independently verified that all reviewers’ comments were addressed but will do this before we ship to the IESG what likely will be -04.

Grüße, Carsten


## Minor

           The option value MUST NOT be less than 8 or greater than 65804.  If
           an option value outside this range is received, the value MUST be
           clamped to this range.

I am still not a fan of re-interpreting disallowed values.
(Assuming there was later any reason to go beyond 65804, of course allowing
larger values and interpreting these as 65804 because a client knowing
just this specification cannot make use of lengths >65804 makes sense.
Not so sure about the values 0..7 though.)

           have been forwarded by an intermediary.  To ensure that this does not
           lead to inconsistent resource state, a stateless intermediary MUST
           include the Request-Tag Option [I-D.ietf-core-echo-request-tag] in
           block-wise transfers with a value that uniquely identifies the client
           in the intermediary's namespace.

-> To ensure that this does not lead to inconsistent resource state, a
stateless intermediary that wants to forward requests with Block1
options will need to also include a distinguishing option such as the Request-Tag Option
[I-D.ietf-core-echo-request-tag] in a way that uniquely...

           When using AES-CCM, repeated use of the same nonce under the same key

Not just AES-CCM, just about any AEAD.  Maybe say: When using an
encryption mode that depends on a nonce, such as AES-CCM, ...


## Nits

           A client SHOULD NOT assume that extended token lengths are supported
           by a server 60 minutes after receiving a response with an extended
           token length, as network addresses may change.

s/60/later than 60/