[core] Benjamin Kaduk's No Objection on draft-ietf-core-senml-etch-05: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 05 September 2019 03:49 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 7F7B2120033; Wed, 4 Sep 2019 20:49:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-core-senml-etch@ietf.org, Carsten Bormann <cabo@tzi.org>, core-chairs@ietf.org, cabo@tzi.org, core@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.100.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <156765535451.22851.10780950548432822644.idtracker@ietfa.amsl.com>
Date: Wed, 04 Sep 2019 20:49:14 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/bdQJfE2W2Nsjx4DxXV944SdZkTQ>
Subject: [core] Benjamin Kaduk's No Objection on draft-ietf-core-senml-etch-05: (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, 05 Sep 2019 03:49:15 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-core-senml-etch-05: 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 IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-core-senml-etch/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Adam raises some good points, and I'm looking forward to seeing the ensuing discussion. Just to double-check: these media types/methods are not suitable for use with streaming lists (SenSML)? I'll also echo the concerns of the genart reviewer about having a note in the body of the document about the trailing "_" behavior of key names for extensibility purposes. I was going to ask for more detail of how this works until I checked RFC 8428, but am only assuming the intent is to "do what 8428 does" -- we should be explicit about it. Section 4 As for several other reviewers I'm not entirely sure that I understand the fragment case for fetch/patch records. These records (the request body) are themselves selectors, so a client that wanted to consider just a subset of the records could just send the (appropriately resolved for base values) subset of the records in the request to obtain the selected set of records from the resource instead of requesting the "full" set (from the request body) and then selecting from the response via the fragment. So, are we just specifying the fragment semantics out of a sense of completeness, or are there expected to be cases where we still want to retrieve records from the server just to "throw them away" at the client side? It is perhaps plausible to imagine doing so with (i)Patch, in order to effect a set of changes but only retain the results for a subset of them, but I'm having a harder time coming up with a case for fetch fragments. The best I can do so far is some (as-yet-to-me) hypothetical case where the selector is easier to write with multiple fetch records (e.g., for getting base values) but not all of them are relevant for the desired computation. Section 5 In FETCH and (i)PATCH requests, the client can pass arbitrary names to the target resource for manipulation. The resource implementer must take care to only allow access to names that are actually part of (or accessible through) the target resource. I am somewhat inclined to think that we should say a bit more about explicitly sanitizing the input names in addition to the current "take care" language, to remove or escape any input that could be interpreted with special meaning by the local system. If the client is not allowed to do a GET or PUT on the full target resource (and thus all the names accessible through it), access control rules must be evaluated for each record in the pack. Does it matter if we think about the ACL as being applied to records in the fetch/patch pack vs. the resource's pack?
- [core] Benjamin Kaduk's No Objection on draft-iet… Benjamin Kaduk via Datatracker
- Re: [core] Benjamin Kaduk's No Objection on draft… Alexey Melnikov