Subject: [Last-Call] Tsvart last call review of draft-ietf-core-echo-request-tag-11

From: Joerg Ott via Datatracker <[email-masked]>
Date: Tue, 01 Dec 2020 14:10:41 -0800

Reviewer: Joerg Ott
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[email-masked] if you reply to or forward this review.

The draft reads well and is essentially ready to go from a transport perspective.

One question that arises is why these three quite distinct mechanisms fixing
different parts of the RFC 7252 are compiled into a single document. Efficiency,
yes, but otherwise, they don't seem to have much in common.

p9, 2nd para, line 5: may -> MAY ?

A question out of curiosity: in section 3.4, could a client easily exhaust server
resources if just sent many blocks and changed the Request-Tag on each of them?

Should sections 3.6 and 3.7 move to an appendix? They discuss design alternatives.

Nits: "can not" -> "cannot"
The last sentence in the second to last paragraph of section 1.1 has nested brackets,
which may or may not be intentional.

---

From: Christian M. Amsüss <[email-masked]>
Date: Wed, 9 Dec 2020 16:09:00 +0100

Hello Jörg,

Thank you for your review and your comments.

> yes, but otherwise, they don't seem to have much in common.

The mechanisms also share common patterns in the attacks they prevent,
and playing through scenarios of one mechsnism led to a better
understanding of the others. It is hoped that the reader can use the
mind set built up understanding the necessity for one mechanism leads to
a better one on the others.

> resources if just sent many blocks and changed the Request-Tag on each of them?

No more than it can by addressing them to different resources (where the
query parameter is part of the underlying identity) -- or even any
made-up uncritical safe-to-forward option. CoAP servers that perform
atomic processing typically have limited slots for these operations
(either global, per resource or per client), and any later request
invalidates the former's state.

> Should sections 3.6 and 3.7 move to an appendix? They discuss design alternatives.

Question for these came up so frequently in discussions around the
document that I think it's better here where it's visible.

Happy to move it over if you or other commenters insist, but that should
happen in awareness of the underlying questions' occurrence.

> which may or may not be intentional.

It's an unintentional occurrence which I'd -- now aware -- also make
consciously to avoid extra prose that'd set aside the defining terms
from the accompanying remarks.

The remaining nits have been addressed in the editors' copy, and will be
part of the next version.

Thanks again
Christian

-- 
You don't become great by trying to be great. You become great by
wanting to do something, and then doing it so hard that you become great
in the process.
  -- Marie Curie (as quoted by Randall Munroe)

---

From: Joerg Ott <[email-masked]>
Date: Wed, 9 Dec 2020 18:41:56 +0100

Hi Christian,

quick responses inline, none of my points were critical concerning
the draft moving forward anyway.

> a better one on the others.

Didn't build up in my mind, but since this is not really important for
the spec I would not want to suggest any extensions for the
introduction.  Let's just move on.

> invalidates the former's state.

Ok, thanks for confirming.

> document that I think it's better here where it's visible.

Does it require this level of visibility?  It feels odd in this place.

> happen in awareness of the underlying questions' occurrence.

It would make sense to move from the perspective of separating normative
from background parts.  One way of addressing the issue could also be
reconsidering how to group second and third level subsections, so that
these two are equal to the others.

But, again, I don't feel strongly.

> part of the next version.

Sounds good.

Best,
Jörg