Re: [core] WG Last Call on draft-ietf-core-new-block

mohamed.boucadair@orange.com Tue, 22 December 2020 18:01 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 352343A11D6; Tue, 22 Dec 2020 10:01:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_H4=0.001, RCVD_IN_MSPIKE_WL=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 e8BuP8olZOsP; Tue, 22 Dec 2020 10:01:29 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17B293A11D5; Tue, 22 Dec 2020 10:01:29 -0800 (PST)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 4D0kfv4gTkzFqMB; Tue, 22 Dec 2020 19:01:27 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1608660087; bh=zmp05u9SivFw0GjfNhWAxGUfkOvEYio/AXuOtHrfSJU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=bwdVuyyXun+Ane5mg1RKLI1jr2YgA3sw7oXSiS/+yXjNhF3P0THzgbHO8WyS5XsAF T6KtpIvCfOFYSFFozhA4g2yfqUWe4JhXPXas39Q+ozU552wySS4+zdanNvBlssYnnf v07VhcaS3p13esPM/0tk9Fdm6Q1YBF28V7+WM10zUrMhj5WQC/j5x/F8IwY6m4bs1k 1q/C4LcGr2IuBpZiQGwwrDcebdKfV1WyEXUJk+aQjoxHmgBRziECzGpvincpZLzdEH QDI4CJDknYaqMAxbufLZ82TUeTjQlDQyMAdJgOhr2aQ5secYc9kSVj1Mrv2mtEujQg EZUouELNJoIJw==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4D0kfv3jQfz3wbM; Tue, 22 Dec 2020 19:01:27 +0100 (CET)
From: mohamed.boucadair@orange.com
To: Marco Tiloca <marco.tiloca@ri.se>, "core@ietf.org WG (core@ietf.org)" <core@ietf.org>
CC: "dots@ietf.org" <dots@ietf.org>
Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block
Thread-Index: AQHW13C+BUBsnnzenkGee3873+vLMqoDaUOg
Date: Tue, 22 Dec 2020 18:01:26 +0000
Message-ID: <12182_1608660087_5FE23477_12182_65_1_787AE7BB302AE849A7480A190F8B9330315A119C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <263d6f84-4a57-2085-288f-068b1d78f7ae@ri.se> <e36b0b27-d802-5726-0605-0a3c4916dc19@ri.se>
In-Reply-To: <e36b0b27-d802-5726-0605-0a3c4916dc19@ri.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/tSLgkXvmZuE1PYwOj-7ErRvpV5E>
Subject: Re: [core] WG Last Call on draft-ietf-core-new-block
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, 22 Dec 2020 18:01:31 -0000

Hi Marco, 

Many thanks for the comments.

All good points. We released a new version that addresses those. A diff to track the changes can be seen at: 
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-new-block-03

Cheers,
Jon & Med

> -----Message d'origine-----
> De : core [mailto:core-bounces@ietf.org] De la part de Marco Tiloca
> Envoyé : lundi 21 décembre 2020 09:10
> À : core@ietf.org WG (core@ietf.org) <core@ietf.org>
> Cc : dots@ietf.org
> Objet : Re: [core] WG Last Call on draft-ietf-core-new-block
> 
> Hi all,
> 
> Please, see below some comments for this WGLC.
> 
> Best,
> /Marco
> 
> 
> [General]
> 
> * s/CoAP endpoint sender/CoAP sender endpoint
> 
> * Please, replace the references to RFC 7049 with references to RFC
> 8949.
> 
> * There are six instances of "CoAP session", which is not defined in
> RFC
> 7252 or RFC 7959. Do you simply mean "block-wise transfer" ?
> 
> 
> [Section 1]
> 
> * I think that the heading of the current Section 1.1 can be
> removed, so that Section 1 starts simply with "The Constrained
> Application Protocol ..."
> 
> * s/and further updated/and was further updated
> 
> * s/loss; which/loss, which
> 
> * s/informs the CoAP endpoint sender either successful receipt
> or/either informs the CoAP sender endpoint of a successful receipt
> or
> 
> * s/that have been not yet been received/that have not yet been
> received
> 
> * s/will both generally/will both be generally
> 
> * The last paragraph in Section 1.4 can be expanded to mention
> OSCORE as an alternative when DTLS is not used.
> 
> 
> [Section 3.4]
> 
> * As to "If the server receives multiple requests (implied or
> otherwise) for the same block ..." , I guess the word "requests"
> does not mean CoAP requests, since the paragraph is talking about a
> single actual CoAP request. In fact, it seems to refer to the
> multiple needed blocks indicated by the multiple Q-Block2 options in
> a same CoAP request.
> 
>    If I'm interpreting correctly, this tries to cover a strange
> behavior from the client that sends multiple Q-Block2 Options in a
> same CoAP requests with the M bit set, such as: 2/1/1024 , 3/1/1024,
> 4/1/1024; but still the server has to send back blocks 2, 3, 4 ...
> until the last one only once each.
> 
>    If this is correct, how about the following rephrasing?
> 
>    "If the request includes multiple Q-Block2 Options and asks for a
> same block multiple times (e.g., through the M bit set), the server
> MUST only send back one instance of that block.
> 
> * s/if this is the case/if this is not the case
> 
> * s/Option whichever is/Option, whichever is
> 
> 
> [Section 3.7]
> 
> * s/and MUST have the same value/and MUST preserve the same value in
> each of those payloads.
> 
> (just to avoid reading it as Size1 and Size2 must have the same
> value)
> 
> 
> [Section 9]
> 
> * I suggest to add one more example in the end, where Q-Block2 is
> used in a request with the M bit set. As a separate continuation of
> the example in Figure 7, this can be the case where, after observe
> being triggered one more time, only the first block for a new ET=24
> reaches the client, which can use a single QB2:1/1/1024.
> 
> 
> [Section 11]
> 
> * As mentioned for Section 1, more can be said here for when OSCORE
> is used.
> 
> 
> 
> On 2020-12-07 18:35, Marco Tiloca wrote:
> > Dear all,
> >
> > Following the recent clarifications from the authors [1], this
> mail
> > starts a Working Group Last Call on:
> >
> > https://tools.ietf.org/html/draft-ietf-core-new-block-02
> >
> > This WGLC will end on Tuesday, 22nd of December.
> >
> > This WGLC is also copied to the DOTS WG mailing list.
> >
> > Best,
> > Marco and Jaime
> >
> > [1]
> >
> https://mailarchive.ietf.org/arch/msg/core/MJRxWldea5EOchYJRBOmkdvji
> LI
> > /
> >
> 
> --
> Marco Tiloca
> Ph.D., Senior Researcher
> 
> RISE Research Institutes of Sweden
> Division ICT
> Isafjordsgatan 22 / Kistagången 16
> SE-164 40 Kista (Sweden)
> 
> Phone: +46 (0)70 60 46 501
> https://www.ri.se
> 


_________________________________________________________________________________________________________________________

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.