Change:
5. <del> [TBD: Fill out the option templates for Echo and Request-Tag] </del> <ins> This section updates the Token processing in Section 5.3.1 of RFC7252 by adding the following text: When CoAP is used with a security protocol not providing bindings between requests and responses, the client MUST NOT reuse tokens until the traffic keys have been replaced.  The easiest way to accomplish this is to implement the Token as a counter, this approach SHOULD be followed. </ins> 6. <del> Servers that store a Echo challenge per client can be attacked for resource exhaustion, and should consider minimizing the state kept per client, e.g. using a mechanism as described in echo-state. </del> <ins> This document adds the following option numbers to the "CoAP Option Numbers" registry defined by RFC7252: 7. Servers SHOULD NOT put any privacy sensitive information in the Echo or Request-Tag option values.  Unencrypted timestamps MAY reveal information about the server such as its system time or location. Servers MUST use a monotonic clock to generate timestamps and compute round-trip times.  Servers SHOULD NOT use their system time for timestamps, as system time is often not monotonic, may reveal that the server will accept expired certificates, or reveal the server's location.  Use of non-monotonic clocks is not secure as the server will accept expired Echo option values if the clock is moved backward.  The server will also reject fresh Echo option values if the clock is moved forward.  An attacker may be able to affect the server's system time in various ways such as setting up a fake NTP server or broadcasting false time signals to radio-controlled clocks. Servers SHOULD use the time since reboot measured in some unit of time.  Servers MAY reset the timer periodically even when not rebooting. The availability of a secure pseudorandom number generator and truly random seeds are essential for the security of the Echo option.  If no true random number generator is available, a truly random seed must be provided from an external source. An Echo value with 64 (pseudo-)random bits gives the same theoretical security level against forgeries as a 64-bit MAC (as used in e.g. AES_128_CCM_8).  In practice, forgery of an Echo option value is much harder as an attacker must also forge the MAC in the security protocol.  The Echo option value MUST contain 32 (pseudo-)random bits that are not predictable for any other party than the server, and SHOULD contain 64 (pseudo-)random bits.  A server MAY use different security levels for different uses cases (client aliveness, request freshness, state synchronization, network address reachability, etc.). The security provided by the Echo and Request-Tag options depends on the security protocol used.  CoAP and HTTP proxies require (D)TLS to be terminated at the proxies.  The proxies are therefore able to manipulate, inject, delete, or reorder options or packets.  The security claims in such architectures only hold under the assumption that all intermediaries are fully trusted and have not been compromised. Servers that use the List of Cached Random Values and Timestamps method described in echo-state may be vulnerable to resource exhaustion attacks.  On way to minimizing state is to use the Integrity Protected Timestamp method described in echo-state. </ins>

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.