[core] Review of draft-ietf-core-echo-request-tag-07

[Francesca Palombini <[e-mail]>]

Hi,

I have taken some time to review draft-ietf-core-echo-request-tag-07. Thank you for this document. As a summary, I think the draft is needed, well written, and on the right track.

I have a couple of suggestions about structure of the document, up to the authors to take them or leave them.

I also have additional questions/open points, which instead need answering and might need clarification text in the document. For some points in the document I have some proposal text to improve readability, based on my understanding.

Finally, I have compiled a list of nits and will soon make a PR for it.

# High level suggestions #

* Move the Terminology section (current section 1.4) as section 1.1 (under Introduction).

* Current sections 1.1, 1.2, 1.3 are very useful background sections about the problem this document sets out to solve. I do not see why they need to be in this order, for readability I would have: 1.1 as new section 2.1, moving the text in 2. to the current 2.1 (that would become 2.2); 1.2 as new section 3.1, moving the text in 3. to current 3.1 (new 3.2); 1.3 as new section 5.1, old 5. text becoming 5.2. This will require mainly copy-paste and minor introductory text in sections 2, 3, and 5.

The goal with this restructuring would be to help keep the 3 parallel topics in focus (Echo options, Request Tag option, Token update), without having to switch from one to the other.

* Move appendix A to the main body: there is already RECOMMENDED text, it would fit to have that as the last subsection of the Echo section.

# Questions, Open points #

* Section 1.4

"   (Concurrent block-wise request operations are impossible with the
   options of [RFC7959] because the second operation's block overwrites
   any state of the first exchange.).
"

I believe this is true, but could you point to the section that states that? I didn't manage to find it while checking.

* Section 2.1

"   When receiving an Echo option in a request, the server MUST be able
   to verify when the Echo option value was generated.  This implies
   that the server MUST be able to verify that the Echo option value was
   generated by the server or some other party that the server trusts.
"

I don't necessarily agree with the "This implies", would just replace with "and". These are two parallel requirements.

* Section 2.1 : event-based freshness is mentioned, but no example of it is given of how that would work with the echo option, while the time based one is quite clear thanks to the example in Figure 2. Would it be possible to add one for an event based as well?

* Section 2.2

"  The server MAY include the same Echo
   option value in several different responses and to different clients.
"

First, I was confused about this: I wondered if "different responses" referred to different response codes or actual responses. I think the answer is both is correct, but here you meant actual responses; this would need more discussion on why re-using the same option value is OK (i.e. highlight this is not a binding of response to next request, it just provides freshness). If that is already done elsewhere, I missed it.

* Section 2.2

"...  the
   server MUST use the Echo option to verify that the request is fresh
   enough. 
"

A RECOMMENDED way of specifying "fresh enough" would be good, to help implementers. For time based, it would be enough to point to Figure 2. For event based, I don't know.

* Section 2.2

"
When used to serve freshness requirements (including client aliveness
   and state synchronizing), CoAP messages containing the Echo option
   MUST be integrity protected between the intended endpoints, e.g.
   using DTLS, TLS, or an OSCORE Inner option ([RFC8613]). 
"

Why do the both messages (request and response) need to be integrity protected? Also Inner option is not used for protecting CoAP messages, but options. So I am a bit confused if here you meant option (which is a different discussion) or message. Also the following sentence ("when used to demonstrate...") belongs with the discussion about the option being Inner or Outer (Section 2.1 4th par), rather than here where we are talking about the message.

* Section 2.3

"
the authority of the property
"

can you explain this terminology?

* Section 3.2

"
  They can
   still be treated as independent messages by the server (e.g. when it
   sends 2.01/2.04 responses for every block), or initiate a new
   operation (overwriting kept context) when the later message carries
   Block1 number 0.
"

I have a hard time parsing/understanding this paragraph, particularly from "or initiate..."

* Section 3.2

I am not sure it is said anywhere what the server should do if it supports the Request-Tag option and it receives it in a non-blockwise message... I guess just discard, but it would be good to explicitely state.

Also, could this option be used for something else? For example, I am thinking of Observe operations, re-registration... Does not need to be defined here, but if we MANDATE that it can only be used with blockwise, we are practically stopping any other use that might come up...

* Section 3.3

"
   Clients MUST NOT recycle a request tag unless the first operation has
   concluded. 
"

in the case where a client supports but does not use Request-Tag, this implies "concurrent block operations without Request-Tag are not allowed". If that is the case, I would like that to be stated explicitely.

(also minor, I'd like to add "that support Request-Tag" after "Clients")

* Section 3.3

The last sentence gives some requirements about where the Request-Tag option can/musty be used per message. I felt the document was missing on usage requirements (e.g. if it is set, it MUST be set for all requests for a specific operation)

* Section 3.4.2

"
   When initializing a new block-wise operation, a client has to look at
   other active operations:

   o  If any of them is matchable to the new one, and the client neither
      wants to cancel the old one nor postpone the new one, it can pick
      a Request-Tag value that is not in use by the other matchable
      operations for the new operation.

   o  Otherwise, it can start the new operation without setting the
      Request-Tag option on it.
"

Does not cover the fact that Request-Tag can be omitted if that is a different from the other matchable operations. ("pick a new value" excludes it)

* Section 3.4.3

I believe this section is missing something on the lines of: 

"Proxies that are aware of this specification can modify their implementation to simply forward block operations."

Would you agree?

* Section 6

Missing references/terminology for monotonic and wall clock.

* Section 6.1

cought a couple of normative text not being normative:

"message must be discarded"

"approach is recommended"

"need to be blacklisted"

Any particular reason why?

Thanks,
Francesca