Re: [core] Éric Vyncke's No Objection on draft-ietf-core-new-block-11: (with COMMENT)

mohamed.boucadair@orange.com Mon, 03 May 2021 12:36 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 38EFD3A0E13; Mon, 3 May 2021 05:36:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.117
X-Spam-Level:
X-Spam-Status: No, score=-2.117 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 rIgmJhM_QDnx; Mon, 3 May 2021 05:36:07 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (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 A51853A0E0F; Mon, 3 May 2021 05:36:06 -0700 (PDT)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar23.francetelecom.fr (ESMTP service) with ESMTP id 4FYjBX5V60zBshl; Mon, 3 May 2021 14:36:04 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620045364; bh=8287P9c2HGTAnPWCFhfEjKtScV0oc4FjJxGJwOxV/4M=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=IUL7zGT7A9gSohZE1vZWFfLzGvl4eM0fJjDyr15GGi8E5vXkywD5VI5azHiCYIRJ7 lqedarG0nFdk8cuOYLSoVgB5iXBr/c9wcABXF0lUh6/1ZNPHHNuHkHAxNrZEOnoLUu IIvZsV8mdINWadz2o3fly42MidMmEkOn8bGNl5BzoH2mzYjWlYDu+FceUTdI+VZi/u ro49/7UnwCCRUoDM3L0d0mZW0vhLFDRUN2++si6qFq7OMwS59SHIfU/bkRGse3ZJ6L 5yxkPBL9RrKSlfmhfg00sDoH+JanYDpMfeaZEx1Osxi+bgL5hjQcpTBGh6MuwsCL8E LMIvQo80yBENQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 4FYjBX3q5rz3wbB; Mon, 3 May 2021 14:36:04 +0200 (CEST)
From: <mohamed.boucadair@orange.com>
To: =?utf-8?B?w4lyaWMgVnluY2tl?= <evyncke@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-core-new-block@ietf.org" <draft-ietf-core-new-block@ietf.org>, "core-chairs@ietf.org" <core-chairs@ietf.org>, "core@ietf.org" <core@ietf.org>, "marco.tiloca@ri.se" <marco.tiloca@ri.se>, "csp@csperkins.org" <csp@csperkins.org>
Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtY29y?= =?utf-8?Q?e-new-block-11:_(with_COMMENT)?=
Thread-Index: AQHXQBY05oJi2PX0SEmSBa0SEhG1K6rRrPZg
Date: Mon, 3 May 2021 12:36:03 +0000
Message-ID: <32469_1620045364_608FEE34_32469_195_1_787AE7BB302AE849A7480A190F8B933035375C5B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <162004421064.19511.6477108778521848512@ietfa.amsl.com>
In-Reply-To: <162004421064.19511.6477108778521848512@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.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/qEwbQKYEzUqGUTpU1-7mI57Fthg>
Subject: Re: [core] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-core-new-block-11=3A_=28with_COMMENT=29?=
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: Mon, 03 May 2021 12:36:12 -0000

Hi Eric, 

Thank you for the comments. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Éric Vyncke via Datatracker [mailto:noreply@ietf.org]
> Envoyé : lundi 3 mai 2021 14:17
> À : The IESG <iesg@ietf.org>
> Cc : draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org;
> core@ietf.org; marco.tiloca@ri.se; marco.tiloca@ri.se;
> csp@csperkins.org
> Objet : Éric Vyncke's No Objection on draft-ietf-core-new-block-11:
> (with COMMENT)
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-core-new-block-11: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut
> this introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-
> criteria.html
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-core-new-block/
> 
> 
> 
> ---------------------------------------------------------------------
> -
> COMMENT:
> ---------------------------------------------------------------------
> -
> 
> Thank you for the work put into this document.
> 
> Please find below some non-blocking COMMENT points (but replies would
> be appreciated especially on the intended status/lack of public
> implementations).
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> 
> !!! I was about to ballot a DISCUSS on this point... In the absence
> of a section about existing implementations for such a new transport,
> I really wonder whether standard track should be used rather then
> experimental. Did the authors/WG run some simulations ?

[Med] There is an implementation and a PR was pushed so that this functionality is supported in the libcoap. Please refer to the following from the write-up:

======
A Pull-Request of an author's implementation to "libcoap" is available at https://github.com/obgm/libcoap/pull/611 

Feedback from the implementation activity has contributed to the design and refinement of specific aspects, notably:

- Limiting new mechanics for congestion control only to CoAP Non-Confirmable messages.
- Not mixing CoAP Confirmable and Non-Confirmable messages for a same request/response body.
- The 'Continue' indication of successfully received blocks.
- The discovery of server support for the Q-Block1 and Q-Block2 Options.
- Further lessons learned highlighted as "Implementation note" in the document.
====

> 
> Happy to have read Colin Perkins' review for the Transport ART, which
> has provided me with some confidence in this brand new transport
> protocol. I am also trusting the TSV Area Directors on this point.
> 
> -- Section 1 --
> I had in mind that constrained network are well protected either at
> layer-2 or by having an air-gap or firewall at their edges, so, a DoS
> seems quite improbable in those deployments.

[Med] One side note: there were reports of "weak" implementations and deployments. You may refer for example to https://futureiot.tech/top-iot-protocols-mqtt-coap-have-major-flaws-warns-trend-micro/ or https://www.zdnet.com/article/the-coap-protocol-is-the-next-big-thing-for-ddos-attacks/. Of course, there are guards out there but deployments may not support them. 

 Should this 'use case'
> really be part of the introduction? Or is it simply linked to the
> DOTS use case ? In either case, the DoS should be more detailed.

[Med] This is mainly driven by the DOTS use case. Not sure which more details you would like see added.   

> 
> -- Section 3 --
> Any reason why 'CON' is not expanded/explained on first use ?

[Med] Actually, it is. Please refer to Section 1:

   As a reminder, [RFC7959]
   recommends the use of Confirmable (CON) responses to handle potential
   packet loss. 

_________________________________________________________________________________________________________________________

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.