Draft: draft-ietf-core-echo-request-tag

Commentary: LGTM . Merging an introduced typo easier .
Paragraph (version A):
This document specifies two server-oriented CoAP options, the Echo
option and the Request-Tag option: 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
(RFC8446), or OSCORE (I-D.ietf-core-object-security), provide the
additional security features.
Paragraph (version B):
This document specifies two server-oriented CoAP options, the Echo
option and the Request-Tag option: The Echo option enables a CoAP
server to verify the freshness of a request, 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 (RFC8446), or OSCORE (I-D.ietf-core-object-
security), provide the additional security features.
Paragraph (version A):
The Echo option is a lightweight server-driven challenge-response
mechanism for CoAP, motivated by the need for a server to verify
freshness of a request as described in req-fresh.  The Echo option
value is a challenge from the server to the client included in a CoAP
response and echoed back to the server in one or more CoAP requests.
Paragraph (version B):
The Echo option is a lightweight server-driven challenge-response
mechanism for CoAP, motivated by the need for a server to verify
freshness of a request as described in req-fresh.  With request
freshness we mean that the server can determine that the client (or
in the case of hop-by-hop security the proxy) sent the request
recently.  The time threshold for being fresh is application
specific.  The Echo option value is a challenge from the server to
the client included in a CoAP response and echoed back to the server
in one or more CoAP requests.
Paragraph (version A):
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.
Paragraph (version B):
The server may use request freshness provided by the Echo option to
verify the aliveness of a client or to synchronize state.  The server
may also include the Echo option in a response to force a client to
demonstrate reachability at their apparent network address.
Paragraph (version A):
A server may want to verify the aliveness of a client by
responding with an Echo option.
Paragraph (version B):
A server may want to use the request freshness provided by the
Echo to verify the aliveness of a client.  Not that in a
deployment with hop-by-hop security and proxies, the server can
only verify aliveness of the closest proxy.