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

Lars Eggert <lars@eggert.org> Wed, 05 May 2021 10:05 UTC

Return-Path: <lars@eggert.org>
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 03D543A0BD7; Wed, 5 May 2021 03:05:41 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org
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 bW2ApJ2TYMLg; Wed, 5 May 2021 03:05:35 -0700 (PDT)
Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (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 E12643A0BD2; Wed, 5 May 2021 03:05:34 -0700 (PDT)
Received: from smtpclient.apple (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 mail.eggert.org (Postfix) with ESMTPSA id C7948600353; Wed, 5 May 2021 13:05:25 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; 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 <lars@eggert.org>
Message-Id: <C1B2D8B7-8D1C-48FD-A17B-D99FA58A6366@eggert.org>
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.80.0.2.43\))
Date: Wed, 5 May 2021 13:05:23 +0300
In-Reply-To: <18631_1620205336_60925F18_18631_96_1_787AE7BB302AE849A7480A190F8B933035376CCC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Cc: The IESG <iesg@ietf.org>, "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>
To: mohamed.boucadair@orange.com
References: <162020162632.31228.3329646750403522840@ietfa.amsl.com> <18631_1620205336_60925F18_18631_96_1_787AE7BB302AE849A7480A190F8B933035376CCC@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
X-MailScanner-ID: C7948600353.AF3E8
X-MailScanner: Found to be clean
X-MailScanner-From: lars@eggert.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/ZOzLnzHB_E9uewVRC9QOXAawEok>
Subject: Re: [core] Lars Eggert's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)
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: Wed, 05 May 2021 10:05:41 -0000

Hi Med,

On 2021-5-5, at 12:02, mohamed.boucadair@orange.com 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 https://datatracker.ietf.org/doc/minutes-interim-2020-core-06-202006101600/, 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., https://datatracker.ietf.org/doc/minutes-110-core-202103121300/: "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.

Thanks,
Lars