[core] Roman Danyliw's No Objection on draft-ietf-core-new-block-11: (with COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 05 May 2021 19:17 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 F36993A1D77; Wed, 5 May 2021 12:17:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw 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: Roman Danyliw <rdd@cert.org>
Message-ID: <162024227267.18682.9364450117778772479@ietfa.amsl.com>
Date: Wed, 05 May 2021 12:17:52 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/3Zohgc3N_je6VMSGQTaYA4RWQTw>
Subject: [core] Roman Danyliw'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: Wed, 05 May 2021 19:17:53 -0000
Roman Danyliw 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: ---------------------------------------------------------------------- ** Section 3.2 and Section 11 (a) Section 3.2. It is not recommended that these options are used in a NoSec security mode (b) Section 11. It is NOT RECOMMENDED that the NoSec security mode is used if the Q-Block1 and Q-Block2 Options are to be used. I believe that the intend of (a) and (b) is to caution against using NoSec mode with either Q-Block1 or 2. One read of (b) would be that this guidance is only about when both options are used together (e.g., the language of Section 4.7). I recommend restating (b) to be more along the lines of: Therefore, it is NOT RECOMMENDED to use the NoSec security mode if either the Q-Block1 or Q-Block2 Options is used. ** Section 4.1. Colloquialism. s/local configuration knob/local configuration option/ ** Section 4.4. (a) If the server detects part way through a body transfer that the resource data has changed and the server is not maintaining a cached copy of the old data, then the transmission is terminated. Any subsequent missing block requests MUST be responded to using the latest ETag and Size2 Option values with the updated data. ... (b) If the server transmits a new body of data (e.g., a triggered Observe notification) with a new ETag to the same client as an additional response, the client should remove any partially received body held for a previous ETag for that resource as it is unlikely the missing blocks can be retrieved. (1) Is (a) suggesting that the missing block requests would be serviced from a copy of the “resource data that has changed”? This would mean that the client would get an inconsistent version of the resource which is neither the old or new version. (2) (b) seems like it is noting that the partially received body should in fact be discarded to avoid the situation in (1). However, how does the client get the initial, now discarded blocks? I’m not sure where that transmission shouldn’t fail with an error as I don’t follow how recover is possible.
- [core] Roman Danyliw's No Objection on draft-ietf… Roman Danyliw via Datatracker
- Re: [core] Roman Danyliw's No Objection on draft-… mohamed.boucadair
- Re: [core] Roman Danyliw's No Objection on draft-… Roman Danyliw