Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT) Wed, 05 May 2021 09:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49D023A18F5; Wed, 5 May 2021 02:02:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.118
X-Spam-Status: No, score=-2.118 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.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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7Vqe2YErHplP; Wed, 5 May 2021 02:02:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D8AD93A18F3; Wed, 5 May 2021 02:02:18 -0700 (PDT)
Received: from (unknown [xx.xx.xx.7]) by (ESMTP service) with ESMTP id 4FZrLw5FTczBrjy; Wed, 5 May 2021 11:02:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1620205336; bh=G2rMWovlfsJQZNFqoIReubU+QAiXOod0Tp0d2cbUWkc=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=fKvjvvmGOwnJkrA7ypTHIhlqTfhXr8/sO7lbigru+/HVqPaWk0UpF8AG4aYBeg8jA TtK/8LHT6CHTrRaZUcORrabb0uCPz3Oq/RkMqZkWIrKORW006VTiTZB8lU1Q99evHb OExtPTVM68+NhPluK1VyW0Nme2/4YsoT+IdQXY7Zlbi6YP8P8U/tLfNrD4nyQ0k7aY FKWS2GDPoCHK1Vt/F8bNyC/kxDVPBRX9Tq5+Syof1hYp2ZTjRZUQKbRUrFv/obRIrK NR1akojQmqOcZTZaUjXFEEQXS0DnA3EimoK3gs3TWcQ1OODxLduX39z556earzu80B /xR2J0CNvLc0g==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.38]) by (ESMTP service) with ESMTP id 4FZrLw3cTQz2xCG; Wed, 5 May 2021 11:02:16 +0200 (CEST)
To: Lars Eggert <>, The IESG <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)
Thread-Index: AQHXQYS466xRZE0VFEm3pHYwmGElFKrUjd9w
Date: Wed, 05 May 2021 09:02:15 +0000
Message-ID: <18631_1620205336_60925F18_18631_96_1_787AE7BB302AE849A7480A190F8B933035376CCC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 May 2021 09:02:24 -0000

Hi Lars, all, 

Please see inline. 


> -----Message d'origine-----
> De : Lars Eggert via Datatracker []
> Envoyé : mercredi 5 mai 2021 10:00
> À : The IESG <>
> Cc :;;
> Objet : Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with
> Lars Eggert has entered the following ballot position for
> draft-ietf-core-new-block-11: Discuss
> 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
> criteria.html
> for more information about DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ---------------------------------------------------------------------
> -
> ---------------------------------------------------------------------
> -
> The current CORE charter does not seem to cover the topic of this
> document. I also see no related milestone.
> Section 1, paragraph 4, discuss:
> >    There is a requirement for these blocks of data to be
> transmitted at
> >    higher rates under network conditions where there may be
> asymmetrical
> >    transient packet loss (i.e., responses may get dropped).  An
> example
> >    is when a network is subject to a Distributed Denial of Service
> >    (DDoS) attack and there is a need for DDoS mitigation agents
> relying
> >    upon CoAP to communicate with each other (e.g.,
> >    [RFC8782][I-D.ietf-dots-telemetry]).  As a reminder, [RFC7959]
> I understand that COAP was initially chosen to transport DOTS
> signaling messages due to their small size, support for structured
> messages and request/response semantics, as well as the ability to
> function over lossy paths such as found in IoT deployment, which COAP
> is architected for.
> DOTS now seems to desire to transport larger messages,

[Med] It is true that DOTS was designed with compact messages in mind, but handling large data was **already** covered in the DOTS spec (see Section 4.4.2 of RFC8782). We then found that the normal block-wise mechanism is suboptimal for the DOTS application.

 and this
> document extends CORE to enable this functionality. However, this
> CORE extension seems to solely focus on Internet deployment
> scenarios, essentially attempting to re-architect COAP into a general
> Internet transport protocol for transmission over paths with high
> loss rates. I do not believe that the CORE WG is chartered to do
> this.

[Med] This work is part of the maintenance of RFC7959 that is covered by the core WG charter:

The working group will perform maintenance on its first four
standards-track specifications:

As you can read in, the WG decided to:
"scope it as an extension (as opposed to blockwise-bis)".

The plan is to use this extension as the base for a bis when the WG will be ready to cover other aspects that are left out of scope for this extension. See, e.g., "it can be seminal material for a blockwise bis document".

I let the AD and the chairs further elaborate on the charter point.


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.