[core] Robert Wilton's No Objection on draft-ietf-core-new-block-11: (with COMMENT)

Robert Wilton via Datatracker <noreply@ietf.org> Thu, 06 May 2021 09:13 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA4D3A198F; Thu, 6 May 2021 02:13:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: 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
X-Test-IDTracker: no
X-IETF-IDTracker: 7.28.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <162029239466.19801.6616209452902790093@ietfa.amsl.com>
Date: Thu, 06 May 2021 02:13:14 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/zkKnOg4UhmBJIzRf4my4JKRs5Ww>
Subject: [core] Robert Wilton's No Objection on draft-ietf-core-new-block-11: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 06 May 2021 09:13:15 -0000

Robert Wilton 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:


I support Lars's discuss.

I am conflicted with how to ballot on this document, and I am also considering
whether to abstain instead.

I appreciate the utility and problem that this is trying to address, but I'm
concerned that this is pushing CoAP outside the IOT domain, and it seems to be
very focused on solving a specific DOTs problem, and seems to make CoAP creep
towards TCP.

I also note that the following paragraph seems to suggest that what is being
done here is somewhat experimental in nature and could even be replaced in
future. Hence I wonder whether publishing as an experimental RFC might be an
alternative, although that does not really answer the question as to whether it
is right to extend CoAP's block handling in this way.

   This mechanism is not intended for general CoAP usage, and any use
   outside the intended use case should be carefully weighed against the
   loss of interoperability with generic CoAP applications.  It is hoped
   that the experience gained with this mechanism can feed future
   extensions of the block-wise mechanism that will both be generally
   applicable and serve this particular use case.