Change:
using short values when the absent option can not be recycled. The Request-Tag options MAY be present in request messages that carry <del> a Block2 option even if those messages are not part of a blockwise request operation (this is to allow the operation described in simpleproxy).  The Request-Tag option MUST NOT be present in response messages, and MUST NOT be present if neither the Block1 nor the Block2 option is present. </del> <ins> no Block option (for example, because a Request-Tag unaware proxy reassembled them), and MUST be ignored in those. The Request-Tag option MUST NOT be present in response messages. </ins> 3.5.

Discussion:
(because they can be created as a consequence of Request-Tag being safe-to-forward), but make them no-ops. as that's the last item in there.
Closed following Francesca's mail at URL
See URL 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. 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. 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
Sounds good to me. And as you pointed out we don't see use other cases right now, anyway. Thanks for addressing my comments. Francesca On 03/03/2020, 13:26, "Christian Amsüss" wrote: Hello Francesca and group, this is the only remaining open discussion point from that review as far as I can tell, but can be closed now as well: A Request-Tag unaware proxy may legitimately reassemble a previously fragmented request-tagged message, creating a legitimate Request-Tag carrying block-free message, so that's being changed to "and MUST be ignored in those" cases. (As request-tagged requests can happen by proxies, that might rule out some of the uses cases.) Kind regards Christian To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom