Change:
option SHOULD contain the client's network address, but MAY be unprotected. <del> A CoAP-to-CoAP proxy MAY respond to requests with 4.01 with an Echo option to ensure the client's reachability at its claimed address, and MUST remove the Echo option it recognizes as one generated by itself on follow-up requests.  However, it MUST relay the Echo option of responses unmodified, and MUST relay the Echo option of requests it does not recognize as generated by itself unmodified. </del> <ins> CoAP-to-CoAP proxy MAY respond to requests with an Echo option, but MUST remove the Echo option it recognizes as one generated by itself on follow-up requests.  However, it MUST relay the Echo option of responses unmodified, and MUST relay the Echo option of requests it does not recognize as generated by itself unmodified.  A CoAP-to-CoAP proxy MAY however add an Echo Option to a response that does not have an Echo Option. </ins> The CoAP server side of CoAP-to-HTTP proxies MAY request freshness, especially if they have reason to assume that access may require it

Discussion:
... and clarify that client aliveness is a cryptographic property. This is in response to comments about the conflict between "OSCORE servers MUST ONLY produce Inner" and "Echo option [...] MAY be unprotected". Contributes-To: URL
Sounds good.
I just noticed there as c09eeaf8088bc62110ea4f8f66199105651e6d90 on this stack as well and (hopefully) simplified that into 456a6f4b28cfc309938511f11dfbc87da25408d7, please have a look there.
Good, looks like an improvement.
“CoAP-to-CoAP proxy MAY set an Echo option on responses, both on forwarded ones that had no Echo option or ones generated by the proxy (from cache or as an error).” I assume a proxy having a cache can generate it’s own requests as well. In these cases the proxy should be allowed to behave like any other client. The current text “However, it MUST relay the Echo option of responses unmodified” kind of give the idea that proxys cannot remove the Echo values.
(from today's telco) "client aliveness" questions lead to the question of who is the client, and from there to which endpoints are involved. From RFC7252's endpoint definition, the security association is part of it. So there are two endpoints involved, the hop-by-hop endpoint (which has no security, or possibly the security of a wrapping DTLS connection) and the end-to-end endpoint (which is OSCORE protected), which may or may not reside on the same host. Different positions of the Echo option relate to communication with different endpoints. It'd be easier to describe the Echo option behavior if that distinction were made explicit in OSCORE, and I don't want to introduce too much of new concepts in here where they don't belong -- finding text to address that might be tricky. (Once words are found to describe that in the Echo text, we'll also have the words to talk about the independent alivenesses of the endpoints, and say that for cryptographically showing "client aliveness" (that's a term there), the aliveness of the inner endpoint must be shown).
I've written up to address the issue we received comments on.

On the topic of endpoints, I found that the text already clearly separates the use case of "client aliveness" and "network reachability"; I've added a word on the aliveness being a cryptographic property and not just another word for the network address being in service, which is hopefully enough for the confusion that has arisen. No need to make things more complicated by pointing out the two server endpoints that are still around there: we never talk of properties that either can have (client aliveness is about the protected endpoint, network reachability is about the unprotected one). If you're happy with , I think we can close this.
Taken care of with