Change:
The Echo option is a server-driven challenge-response mechanism for CoAP.  The Echo option value is a challenge from the server to the <del> client included in a CoAP response and echoed in a CoAP request. </del> <ins> client included in a CoAP response and echoed in one or more CoAP request. </ins> 2.1. The Echo Option is elective, safe-to-forward, not part of the cache- key, and not repeatable, see echo-table. <del> The value of the Echo option MUST be a (pseudo-)random bit string of a length of at least 64 bits.  A new (pseudo-)random bit string MUST be generated by the server for each use of the Echo option. </del> <ins> [Note to RFC editor: If this document is not released together with OSCORE but before it, the following paragraph and the "E" column above need to move into OSCORE.] The Echo option value is generated by the server, and its content and structure are implementation specific.  Different methods for generating Echo option values are outlined in echo-state.  Clients and intermediaries MUST treat an Echo option value as opaque and make no assumptions about its content or structure. When receiving an Echo option in a request, the server MUST be able to verify that the Echo option value was generated by the server as well as the point in time when the Echo option value was generated. </ins> 2.2. <del> It is important to identify under what conditions a CoAP request to a </del> <ins> The Echo option MAY be included in any request or response (see echo- app for different applications), but the Echo option MUST NOT be used with empty CoAP requests (i.e.  Code=0.00). If the server receives a request which has freshness requirements, the request does not contain a fresh Echo option value, and the server cannot verify the freshness of the request in some other way, the server MUST NOT process the request further and SHOULD send a 4.01 Unauthorized response with an Echo option. The application decides under what conditions a CoAP request to a </ins> resource is required to be fresh.  These conditions can for example include what resource is requested, the request method and other data in the request, and conditions in the environment such as the state of the server or the time of the day. <del> A server MAY include the Echo option in a response.  The Echo option MUST NOT be used with empty CoAP requests (i.e.  Code=0.00).  If the server receives a request which has freshness requirements, and the request does not contain the Echo option, the server SHOULD send a 4.01 Unauthorized response with a Echo option.  The server SHOULD cache the transmitted Echo option value and the response transmit time (here denoted t0). Upon receiving a response with the Echo option within the EXCHANGE_LIFETIME (RFC7252) of the original request, the client SHOULD echo the Echo option with the same value in a new request to the server.  Upon receiving a 4.01 Unauthorized response with the Echo option in response to a request within the EXCHANGE_LIFETIME of the original request, the client SHOULD resend the original request. The client MAY send a different request compared to the original request. If the server receives a request which has freshness requirements, and the request contains the Echo option, the server MUST verify that the option value equals a cached value; otherwise the request is not processed further.  The server MUST calculate the round-trip time RTT = (t1 - t0), where t1 is the request receive time.  The server MUST only accept requests with a round-trip time below a certain threshold T, i.e. RTT < T, otherwise the request is not processed further, and an error message MAY be sent.  The threshold T is application specific, its value depends e.g. on the freshness requirements of the request.  An example message flow is illustrated in echo-figure. When used to serve freshness requirements, CoAP messages containing the Echo option MUST be integrity protected, e.g. using DTLS or OSCORE (I-D.ietf-core-object-security). If the server loses time synchronization, e.g. due to reboot, it MUST delete all cached Echo option values and response transmission times. Constrained server implementations can use the mechanisms outlined in echo-state to minimize the memory impact of having many unanswered Echo responses. CoAP-CoAP proxies MUST relay the Echo option unmodified, and SHOULD NOT cache responses when a Echo option is present in request or response for more than the exchange.  CoAP-HTTP proxies MAY request freshness, especially if they have reason to assume that access may require it (eg. because it is a PUT or POST); how this is determined is out of scope for this document.  HTTP-CoAP-Proxies SHOULD respond </del> <ins> The server may also include the Echo option in a response to verify the aliveness of a client, to synchronize state, or to force a client to demonstrate reachability at their apparent network address. Upon receiving a 4.01 Unauthorized response with the Echo option, the client SHOULD resend the original request with the addition of an Echo option with the received Echo option value.  The client MAY send a different request compared to the original request.  Upon receiving any other response with the Echo option, the client SHOULD echo the Echo option value in a next request to the server.  The client MAY include the same Echo option value in several different requests to the server. Upon receiving a request with the Echo option, the server determines if the request has freshness requirement.  If the request does not have freshness requirements, the Echo option MAY be ignored.  If the request has freshness requirements and the server cannot verify the freshness of the request in some other way, the server MUST verify that the Echo option value was generated by the server; otherwise the request is not processed further.  The server MUST then calculate the round-trip time RTT = (t1 - t0), where t1 is the request receive time and t0 is the transmit time of the response that included the specific Echo option value.  The server MUST only accept requests with a round-trip time below a certain threshold T, i.e. RTT < T, otherwise the request is not processed further, and an error message MAY be sent.  The threshold T is application specific, its value depends e.g. on the freshness requirements of the request.  An example message flow is illustrated in echo-figure. When used to serve freshness requirements (including client aliveness and state synchronizing), CoAP requests containing the Echo option MUST be integrity protected, e.g. using DTLS, TLS, or OSCORE (I- D.ietf-core-object-security).  When used to demonstrate reachability at their apparent network address, the Echo option MAY be used without protection. Note that the server does not have to synchronize the time used for the Echo timestamps with any other party.  If the server loses time synchronization, e.g. due to reboot, it MUST reject all Echo values that was created before time synchronization was lost. CoAP-CoAP proxies MUST relay the Echo option unmodified.  The CoAP server side of CoAP-HTTP proxies MAY request freshness, especially if they have reason to assume that access may require it (e.g. because it is a PUT or POST); how this is determined is out of scope for this document.  The CoAP client side of HTTP-CoAP-Proxies SHOULD respond </ins> to Echo challenges themselves if they know from the recent establishing of the connection that the HTTP request is fresh. Otherwise, they SHOULD respond with 503 Service Unavailable, Retry- <del> After: 0 and terminate any underlying Keep-Alive connection.  It MAY also use other mechanisms to establish freshness of the HTTP request that are not specified here. </del> <ins> After: 0 and terminate any underlying Keep-Alive connection.  They MAY also use other mechanisms to establish freshness of the HTTP request that are not specified here. </ins> 2.3. Actuation requests often require freshness guarantees to avoid <del> accidental or malicious delayed actuator actions. </del> <ins> accidental or malicious delayed actuator actions.  In general, all non-safe methods (e.g.  POST, PUT, DELETE) may require freshness guarantees for secure operation. </ins> To avoid additional roundtrips for applications with multiple actuator requests in rapid sequence between the same client and

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.