[core] Chair's review of draft-ietf-core-echo-request-tag-03.txt

[Carsten Bormann <[e-mail]>]

In preparation for the impending working-group last call, I have
reviewed draft-ietf-core-echo-request-tag-03.txt.  Substantive
comments are below; a set of small editorial comments is going to the
authors in parallel.

Grüße, Carsten


# Major

Completely outlawing token reuse is throwing out the baby with the
bathwater -- requiring stable storage for token numbers even in
situations where that is not needed.  (Of course, if you have that,
keeping a token counter e.g. per DTLS connection is a great
implementation strategy.)  Instead, the recommendations about Token
reuse should be specific to the cases covered.  This does require some
additional work.  (The actual wording in Section 5 is closer to
reason, but the introductory material gives a different impression.)

The wording in Section 5 needs to be clarified that this is a
requirement on clients, not a license to servers to base their
operations on the assumption that this requirement is always fulfilled
by a client -- the token processing rules of RFC 7252 still apply.

# Minor

* The document fails to mention that the "echo" function can also be
  provided at the application layer, e.g., with freshness tokens in
  "forms", as they are widely used with HTTP.  It should make clearer
  that "Echo" is just a convention to provide these freshness tokens, in
  particular when there is no natural way to keep the freshness tokens
  in the application data.

* Is "operation" the term we want to use henceforth?

* The "MUST NOT process" in 2.2 is weird, as it is qualified by the
  undetermined "has freshness requirements".  Maybe the text should
  focus on the concept of "fresh enough", which would also explain the
  license for the client to re-use Echo values in further requests.
  The time-based processing model ("RTT < T") is one way to handle
  "fresh enough", but certainly not a MUST -- there are event-based
  freshness models.

* 2.2: Clarify "The CoAP client side of HTTP-to-CoAP proxies SHOULD
  respond to Echo challenges themselves"

* 2.3 item 2 (time and state sync) is very opaque; its statements have
  not been analyzed in this review.

* Section 3 is confused about Request-Tag Options and lists of those.
  Why was the option marked repeatable?
  Or, what is wrong with a non-repeatable Request-Tag Option that
  defaults to the empty string (as opposed to a repeatable one that by
  definition defaults to the empty array/"list")?

* Section 6 (Security Considerations) MUST NOT use BCP14 language.
  Move the mandates up to where they belong.  "Is not allowed" about
  implementation strategies also is weird requirements language (in
  particular when the prohibition is just a result on some other
  implementation choices that aren't really required).

* Requiring a monotonic clock is a consequence of the implementation
  model proposed (time-based freshness) and is not needed with other
  forms of freshness.  In any case, if the non-monotonisms are limited
  to below the freshness requirements (as they would be for most
  usages of civil time), the are inconsequential, so these security
  considerations require some qualification even when phrased as such.
  Monotonic vs. wall-clock is somewhat orthogonal to non-hackable
  vs. hackable, anyway.

* Appendix A could contain some help with the selection of n.

# Editorial

* Title and Abstract.  The title probably should mention CoAP.  The
  abstract might want to say what the introduction already says: This
  is for supporting specific use cases (i.e., not all use cases will
  need these additions).

* Introduction.  The introduction could say earlier that Request-Tag
  is intended exclusively for combination with Block1 options.

* Section 2 would benefit from discussing freshness as a concept
  first, and then introducing the Echo Option as one convention to
  achieve the objectives.  In particular it should be clear that the
  rendition of Echo with a 4.01 may be an unusual case in many
  applications.

* Section 3 would benefit from explaining that Request-Tag is only
  meant to be used with Block1 Options in requests.