Change:
Abstract <del> This document defines two optional extensions to the Constrained Application Protocol (CoAP): the Echo option and the Request-Tag option.  Each of these options when integrity protected, such as with DTLS or OSCORE, protects against certain attacks on CoAP message exchanges. The Echo option enables a CoAP server to verify the freshness of a request by requiring the CoAP client to make another request and include a server-provided challenge.  The Request-Tag option allows the CoAP server to match message fragments belonging to the same request message, fragmented using the CoAP Block-Wise Transfer mechanism.  This document also specifies additional processing requirements on Block1 and Block2 options. </del> <ins> This document specifies several security enhancements to the Constrained Application Protocol (CoAP).  Two optional extensions are defined: the Echo option and the Request-Tag option.  Each of these options provide additional features to CoAP and protects against certain attacks.  The document also updates the processing requirements on the Block options and the Token.  The updated Token processing ensures secure binding of responses to requests. </ins> 1. <del> The initial CoAP suite of specifications (RFC7252, RFC7641, RFC7959) was designed with the assumption that security could be provided on a separate layer, in particular by using DTLS (RFC6347).  However, for some use cases, additional functionality or extra processing is needed to support secure CoAP operations. </del> <ins> The initial Constrained Application Protocol (CoAP) suite of specifications (RFC7252, RFC7641, and RFC7959) was designed with the assumption that security could be provided on a separate layer, in particular by using DTLS (RFC6347).  However, for some use cases, additional functionality or extra processing is needed to support secure CoAP operations.  This document specifies several security enhancements to the Constrained Application Protocol (CoAP). </ins> This document specifies two server-oriented CoAP options, the Echo <del> option and the Request-Tag option, addressing the security features request freshness and fragmented message body integrity, respectively.  These options in themselves do not replace the need for a security protocol; they specify the format and processing of data which, when integrity protected in a message, e.g. using DTLS (RFC6347) or OSCORE (I-D.ietf-core-object-security), provide those security features.  The Request-Tag option and also the ETag option are mandatory to use with Block1 and Block2, respectively, to secure blockwise operations with multiple representations of a particular resource as is specified in this document. Additional applications of the options are introduced.  For example, Echo can be used to mitigate amplification attacks. </del> <ins> option and the Request-Tag option, mainly addressing the security features request freshness and fragmented message body integrity, respectively.  The Echo option enables a CoAP server to verify the freshness of a request, verify the aliveness of a client, synchronize state, or force a client to demonstrate reachability at its apparent network address.  The Request-Tag option allows the CoAP server to match message fragments belonging to the same request, fragmented using the CoAP Block-Wise Transfer mechanism, which mitigates attacks and enables concurrent blockwise operations.  These options in themselves do not replace the need for a security protocol; they specify the format and processing of data which, when integrity protected using e.g.  DTLS (RFC6347), TLS (RFC5246), or OSCORE (I- D.ietf-core-object-security), provide the additional security features. The document also updates the processing requirements on the Block1 option, the Block2 option, and the Token.  The updated blockwise processing secure blockwise operations with multiple representations of a particular resource.  The updated Token processing ensures secure binding of responses to requests. </ins> 1.1. <del> A CoAP server receiving a request may not be able to verify when the request was sent by the CoAP client.  This remains true even if the request was protected with a security protocol, such as DTLS.  This makes CoAP requests vulnerable to certain delay attacks which are particularly incriminating in the case of actuators (I-D.mattsson- core-coap-actuators).  Some attacks are possible to mitigate by establishing fresh session keys (e.g. performing the DTLS handshake) for each actuation, but in general this is not a solution suitable for constrained environments. </del> <ins> A CoAP server receiving a request is in general not able to verify when the request was sent by the CoAP client.  This remains true even if the request was protected with a security protocol, such as DTLS. This makes CoAP requests vulnerable to certain delay attacks which are particularly incriminating in the case of actuators (I- D.mattsson-core-coap-actuators).  Some attacks are possible to mitigate by establishing fresh session keys (e.g. performing the DTLS handshake) for each actuation, but in general this is not a solution suitable for constrained environments. </ins> A straightforward mitigation of potential delayed requests is that the CoAP server rejects a request the first time it appears and asks

Discussion:
I did quite a lot of changes to the Echo parts as discussed earlier. The Echo parts are now clearer updated in requirements and general processing, and example implementations for Token Option Values. I wrote a reasonably long security consideration chapter and added the missing IANA section. I added updated Token handling which requires some changes to abstract and introduction. Removed some definitions that were not used. I have not touched the Request-Tag parts except for maybe some editorials.
I think you should already have write access to the repository; if you can't just push your changes, I'm afraid you'll have to ask Carsten to add you to the team at URL I'm merging this now to get things on, and am trying to add some fixes today still to upload this evening's state before the cut-off. A suggestion w/rt the pull request branches: could you just add commits rather than appending them (unless you're changing around in the same place)? That'd make it much easier to update one's mental model of the document.
The terms "blockwise request operation" and "blockwise response operation" are used (the former frequently, the latter only once), so I've reverted the line that drops them to their previous state in 382c308f3.