[core] Benjamin Kaduk's No Objection on draft-ietf-core-echo-request-tag-13: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-core-echo-request-tag-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-echo-request-tag/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I really like the changes made in the -13 overall; thank you for adding
in all the additional discussion.

I only have editorial/nit-level comments remaining.

Section 2.5.2

   The information extracted by the server from the request Echo value
   has different sources of truth depending on the application.

I think that the "sources of truth" phrase might be a source of
confusion for some readers.
I'd consider something more like:

% The request Echo value conveys freshness information to the server,
% and the freshness is applied to some data or information related
% to the request.

which then transitions decently into "Understanding who or what is the
authoritative source of that information helps the server implementer
decide ..."

   If all that the server extracts is information which the client is
   authorized to provide arbitrarily, (which is another way of saying
   that the server has to trust the client on whatever Echo is used
   for), then the server can issue Echo values that do not need to be

(nit) I'd suggest "whatever Echo is being used for" (add "being")

   In most other cases, there are properties extracted of which the
   server is the authority ("The request must not be older than five
   minutes" is counted on the server's clock, not the client's) or which

[If my above suggestion is used, that removes the word "extracted", this
use of "extracted" should probably be reworded as well.]

Section 3.5.1

      When security services are provided by DTLS, this can only be
      confirmed if there was no CoAP retransmission of the request, the
      request was responded to, and the server performs replay
      protection.

(nit) I think the server would either "perform replay detection" or
"[provide/use] replay protection" -- performing protection is not a
common phrasing.

   way, the server can rely on a conforming client to set the Request-
   Tag option when required, and thereby have confidence the integrity
   of the assembled body.

(nit) "have confidence in"

Appendix A

   This method is suitable both for time and for event base freshness
   (e.g. by clearing the cache when an event occurs), and independent of
   the client authority.

(nit) "for time- and for event-based freshness" (and again a couple
paragraphs later)