Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)

Lars Eggert <> Wed, 05 May 2021 10:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03D543A0BD7; Wed, 5 May 2021 03:05:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bW2ApJ2TYMLg; Wed, 5 May 2021 03:05:35 -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 E12643A0BD2; Wed, 5 May 2021 03:05:34 -0700 (PDT)
Received: from (unknown [IPv6:2a00:ac00:4000:400:54ca:2d0:fd87:7c95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id C7948600353; Wed, 5 May 2021 13:05:25 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dkim; t=1620209125; bh=1fIzkmsFymrzmZrK0+MqGBaK7hYEMA2907p71dOFm2k=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=aDsvgZjz+WWYYb/rKcUwPTS323GN4VncOSk+bhuxyj9kpVtbnoB3H2WfkjfIO/9je X96DikGwllKTNM9m+xBmRjusVyivOmvGt3947FGwYc5bsXhiq65+mD9awCaVcFWhnn JW9pTYuJ4oTy0xWZkrDRQ3DP4RwWE7wMzAlfWdos=
From: Lars Eggert <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_DE96EDC5-5CAB-40B4-9971-BDFB34FCF511"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Wed, 05 May 2021 13:05:23 +0300
In-Reply-To: <18631_1620205336_60925F18_18631_96_1_787AE7BB302AE849A7480A190F8B933035376CCC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Cc: The IESG <>, "" <>, "" <>, "" <>, "" <>
References: <> <18631_1620205336_60925F18_18631_96_1_787AE7BB302AE849A7480A190F8B933035376CCC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3654.
X-MailScanner-ID: C7948600353.AF3E8
X-MailScanner: Found to be clean
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 10:05:41 -0000

Hi Med,

On 2021-5-5, at 12:02, wrote:
> [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:
> ==

those four specifications are RFC 6690, RFC 7252, RFC 7641 and draft-ietf-core-block (= RFC7959).

In my understanding, draft-ietf-core-new-block is a separate COAP extension, not a maintenance effort related to RFC7959. The abstract even says that the new mechanisms are similar to, but not a replacement for, RFC 7959. If it were maintenance, draft-ietf-core-new-block would replace or at the very least update some parts of RFC7959.

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

I think this decision is exactly were the WG went beyond its charter.

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

Until that plan has consensus and is chartered, draft-ietf-core-new-block IMOR remains a COAP extensions that is out-of-charter.

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

I'm sure we'll discuss this on the call tomorrow.