Re: [Tsv-art] Tsvart last call review of draft-ietf-core-echo-request-tag-11

Joerg Ott <ott@in.tum.de> Wed, 09 December 2020 17:42 UTC

Return-Path: <ott@in.tum.de>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1723A117F; Wed, 9 Dec 2020 09:42:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkYDebbnaPel; Wed, 9 Dec 2020 09:42:05 -0800 (PST)
Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.in.tum.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28433A160E; Wed, 9 Dec 2020 09:42:02 -0800 (PST)
Received: by mail.in.tum.de (Postfix, from userid 107) id EC9ED1C12CB; Wed, 9 Dec 2020 18:41:58 +0100 (CET)
Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id E357B1C121A; Wed, 9 Dec 2020 18:41:56 +0100 (CET) (Extended-Queue-bit tech_esegn@fff.in.tum.de)
To: "Christian M. Amsüss" <christian@amsuess.com>, Joerg Ott <jo@acm.org>
Cc: tsv-art@ietf.org, draft-ietf-core-echo-request-tag.all@ietf.org, last-call@ietf.org, core@ietf.org
References: <160686064132.16683.9970897893331887294@ietfa.amsl.com> <X9DojFWbrAWXVTPS@hephaistos.amsuess.com>
From: Joerg Ott <ott@in.tum.de>
Message-ID: <437bf045-8e8b-9870-d333-f4409d4537d2@in.tum.de>
Date: Wed, 09 Dec 2020 18:41:56 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.5.1
MIME-Version: 1.0
In-Reply-To: <X9DojFWbrAWXVTPS@hephaistos.amsuess.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/w3ezsMIqbu-i46eYForWBvIFpzY>
Subject: Re: [Tsv-art] Tsvart last call review of draft-ietf-core-echo-request-tag-11
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Dec 2020 17:42:08 -0000

Hi Christian,

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

>> 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.
> 
> 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.

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.

>> 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?
> 
> 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.

Ok, thanks for confirming.

>> 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.

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

> Happy to move it over if you or other commenters insist, but that should
> 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.

>> The last sentence in the second to last paragraph of section 1.1 has nested brackets,
>> 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.

Sounds good.

Best,
Jörg