[core] Roman Danyliw's Discuss on draft-ietf-core-senml-etch-05: (with DISCUSS and COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 04 September 2019 18:45 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 60854120CA0; Wed, 4 Sep 2019 11:45:44 -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-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: Roman Danyliw <rdd@cert.org>
Message-ID: <156762274438.22762.9096288445438923152.idtracker@ietfa.amsl.com>
Date: Wed, 04 Sep 2019 11:45:44 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/MRWevHKBxDRh-GBACsapc-_63dI>
Subject: [core] Roman Danyliw's Discuss on draft-ietf-core-senml-etch-05: (with DISCUSS and 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, 04 Sep 2019 18:45:45 -0000
Roman Danyliw has entered the following ballot position for draft-ietf-core-senml-etch-05: Discuss 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/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) Section 5. It’s helpful that this document notes the relevance of SenML’s security and privacy considerations (i.e., Section 13 of RFC8428). However, this references seems circular. RFC8428 says, “SenML formats alone do not provide any security and instead rely on the protocol that carries them to provide security.” This document seems to be that “protocol that carries them” implying it should cover the security mechanisms. Is it not appropriate to suggest that CoAPs can address the (per RFC8428) “confidentiality, data integrity, and authentication as appropriate for the usage.”? If not, what additional guidance can be provided? (2) Section 5. It seems like it would be appropriate for the server to support access control to restrict the client’s ability access and modify a resource with FETCH and (i)PATCH. My read of “Per “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”, doesn’t suggest that type of access control. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (3) Section 3.1. A few questions about how general purpose of a query language is possible with the FETCH: -- (To confirm based on the text “The SenML Records are selected by giving a set of names that …”) Does a name always have to be in the Fetch Request (i.e., ‘at least one “n” MUST be in the Fetch Request’)? Using the third example in Section 5.1.2 of RFC8428 as a source: -- The current text mentions that names and time can be in the Fetch Pack request. Can other fields also be used as part of the criteria, say “v”? For example, would ‘{“n”:” urn:dev:ow:10e2073a01080063”, “v”:”21.5”}’ return the three name+time records where the value is 21.5? (4) Section 3.1. If there is no match for a Fetch, how is that signaled back in the response? Is there any guidance to provide on error handling via CoAP error codes? (5) Editorial Nits: -- Section 3.1. s/When SenML Records contain also time values/When SenML Records also contain time values/
- [core] Roman Danyliw's Discuss on draft-ietf-core… Roman Danyliw via Datatracker
- Re: [core] Roman Danyliw's Discuss on draft-ietf-… Ari Keränen
- Re: [core] Roman Danyliw's Discuss on draft-ietf-… Roman Danyliw
- Re: [core] Roman Danyliw's Discuss on draft-ietf-… Ari Keränen