Re: [core] Iotdir telechat review of draft-ietf-core-new-block-11

mohamed.boucadair@orange.com Tue, 04 May 2021 06:46 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D2E3A2810; Mon, 3 May 2021 23:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
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 O8hQi99rBwmK; Mon, 3 May 2021 23:46:48 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E173A280F; Mon, 3 May 2021 23:46:47 -0700 (PDT)
Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 4FZ9P03J6kz4wkg; Tue, 4 May 2021 08:46:44 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620110804; bh=T2MnuO8a7adqP8hzhba/7QI5RiRW+1kbgT03jjAyMAE=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=PzUzDjCbTf9wJmGpy+FNwbLQIq74zm6PUQCJ2QrzumEcjkf1JXYoRq5CNZWaXdvEx 3qUuskAWhRqsihVLlhXMRFDGC3ub+ZzzauWLbk034wV6putZK56LPUDDDyBgChb25k A+h/+ze252Il1mM/mbTZ0Ql6758MxTJKudopEzGBrEaeYtOmnOzvfqtCVaivm9Qg1J VqcfYuhCs8O9Yr/jln+V/xOlWx1JSUn1tZKzpkKNqHaBEHjvN6Dvz5CCi3fKdjYX73 CHmV3kEImgR1noCK+oAAQXt2ivXAO/FtlDigCOUeX0+dwP+0fTW8mfy2GWxouwVPz8 Fab6hyTI6nYyQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.86]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 4FZ9P01xg1z8sYX; Tue, 4 May 2021 08:46:44 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>, "iot-directorate@ietf.org" <iot-directorate@ietf.org>
CC: "core@ietf.org" <core@ietf.org>, "draft-ietf-core-new-block.all@ietf.org" <draft-ietf-core-new-block.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: Iotdir telechat review of draft-ietf-core-new-block-11
Thread-Index: AQHXQC6pZ+6l5oMxxEK4DOYhqxchnKrSzSzw
Date: Tue, 4 May 2021 06:46:43 +0000
Message-ID: <3417_1620110804_6090EDD4_3417_461_1_787AE7BB302AE849A7480A190F8B93303537633E@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <162005471461.25481.16323677090483356173@ietfa.amsl.com>
In-Reply-To: <162005471461.25481.16323677090483356173@ietfa.amsl.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.245]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/i8Lm6lvn5hPXCkb4Y6lGlOvvrYE>
Subject: Re: [core] Iotdir telechat review of draft-ietf-core-new-block-11
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 May 2021 06:46:53 -0000

Hi Emmanuel, 

Thank you for the review. 

You may track the changes at: https://tinyurl.com/new-block-latest.

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Emmanuel Baccelli via Datatracker [mailto:noreply@ietf.org]
> Envoyé : lundi 3 mai 2021 17:12
> À : iot-directorate@ietf.org
> Cc : core@ietf.org; draft-ietf-core-new-block.all@ietf.org; last-
> call@ietf.org
> Objet : Iotdir telechat review of draft-ietf-core-new-block-11
> 
> Reviewer: Emmanuel Baccelli
> Review result: Ready with Nits
> 
> iotdir telechat review of draft-ietf-core-new-block-11 Emmanuel
> Baccelli, 3 May 2021
> 
> ====
> Summary
> ====
> 
> Many thanks for this document. In general, the spec is well written
> as far as I could see. I have a few nits and suggestions (see below).
> 
> My main question is about the use of Confirmable messages. Maybe I
> missed something, but it seems to me the use of CON messages is not
> recommended in the spec, but is nevertheless evoked in the spec. Is
> there room for simplification, or is it considered too "radical" to
> only specify the use of Q-Block with non-confirmable messages?

[Med] We need to cover both CON/NON for the general interoperability and also because we use at least one CON to detect the functionality support. However, the performance benefit is only supported for NON as this is the main applicability scope. As noted in the spec, the performance benefit may also be achieved for CON but this requires NSTART and other parameters. Adjusting these parameters is out of scope.

> 
> Details below.
> 
> Best regards,
> 
> Emmanuel
> 
> ====
> Comments
> ====
> 
> # Section 1
> 
> ## Second to last sentence:
> "such a recommendation does not work with a flooded pipe DDoS
> situation."
> => an explicit ref would feel natural at this point of the text
> (RFC8782 again?
> Or another ref?).

[Med] We can cite it again if this helps.

> 
> ## Last sentence:
> Ends a little dry. How about completing it with something similar to:
> OLD: "This document introduces the CoAP Q-Block1 and Q-Block2 Options
> (Section 3)" NEW: "This document introduces the CoAP Q-Block1 and Q-
> Block2 Options which allow block-wise transfer to work with series of
> Non-confirmable messages, instead of lock-stepping using CON
> messages".
> 

[Med] Works for us. Thanks. 

> # Section 3
> It would read more naturally to my eyes if you'd swap around the
> section's content in the beginning (part before 3.1 begins) like
> this:
>  - move up the overview of the Q-Block options, i.e essentially the
> part
>  "Q-Block1 and Q-Block2 Options are designed to work in particular
> with NON  requests and responses..." and onwards; - gather afterwards
> the bullet points  summing up the advantages / limitations /drawbacks
> of Q-Block options compared  to the Block options.
> 

[Med] We rearranged the text as shown in the diff.   

> # Section 4.1
> the first time you mention POST, PUT? FETCH, iPATCH etc., I suggest
> you explicitly cite RFC8132 again.

[Med] Not sure why it is needed again. 

> 
> # Section 4.3, for Response code 4.13
> "If a server receives payloads with different Request-Tags for the
> same resource, it should continue to process all the bodies as it has
> no way of determining which is the latest version, or which body, if
> any, the client is terminating the transmission for." => since this
> is a *should* and not a MUST, would it make sense to add reassuring
> an implementer note on how to comply while minimzing buffer memory
> requirements? Are there use cases where the server is *very*
> constrained in RAM for instance (say: Class 1 devices in RFC 7228)?

[Med] It is unlikely for the target DOTS case, but this is possible if the mechanism is used in other contexts. 

Nothing much can be done if a server cannot take a large block of data. The application design will need to look at restricting the amount of data that needs to be transferred.

> 
> # Section 7.1
> Do I understand correctly that this configuration (all confirmable
> messages for a given body) is *not* recommended? The statement "it is
> expected that all requests and responses using Q-Block1 and Q-Block2
> will be Non-confirmable" is confusing at first sight,

[Med] We have already updated this text for better clarity. Please see the diff.  

 it begs the
> question: why specify the configuration using CON, then? But maybe I
> missed something.

[Med] We need to cover it in case an endpoint elects to use CON.   

> 
> # Section 11
> If the Request-tag happens to be an outer option (or if there is a
> proxy) does the above comment on section 4.3 (response code 4.13)
> translate in a potential resource exhaustion vulnerability for the
> server?
> 

[Med] The text says that it is not recommended NoSec as OSCORE does not provide the outer wrapper tampering security.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.