Re: [core] Roman Danyliw's Discuss on draft-ietf-core-senml-etch-05: (with DISCUSS and COMMENT)
Roman Danyliw <rdd@cert.org> Tue, 05 November 2019 19:43 UTC
Return-Path: <rdd@cert.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 4E7BF120AF6; Tue, 5 Nov 2019 11:43:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=cert.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 E7Wiw-9ZB0HQ; Tue, 5 Nov 2019 11:43:56 -0800 (PST)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743D5120AF4; Tue, 5 Nov 2019 11:43:56 -0800 (PST)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id xA5Jhb7d046304; Tue, 5 Nov 2019 14:43:37 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu xA5Jhb7d046304
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1572983017; bh=RoLnNh+zDdID78Y2NrHE8Xe/92ocIQ0+DRw8IPwb2H4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=JvMMYoGZGrxj3K2Ec4P0tYpNk244fJPpU8kMrtvwkHJOTVmIYIfNQFHlIJ30RrERk 94Ee578BAnAGkRmyh/DSfA9w2YqtY7GwdNSpYqlPQ5InhENM8s7AIfGzigTfBWbZeu hKR+emv76hF3NVjl5KUzLU20DApYV15DWHxUHuck=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id xA5JhkMP018643; Tue, 5 Nov 2019 14:43:46 -0500
Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0468.000; Tue, 5 Nov 2019 14:43:45 -0500
From: Roman Danyliw <rdd@cert.org>
To: Ari Keränen <ari.keranen@ericsson.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-core-senml-etch@ietf.org" <draft-ietf-core-senml-etch@ietf.org>, Carsten Bormann <cabo@tzi.org>, "core-chairs@ietf.org" <core-chairs@ietf.org>, "core@ietf.org" <core@ietf.org>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-core-senml-etch-05: (with DISCUSS and COMMENT)
Thread-Index: AQHVkpsKK/Mq8+8GK0mm/UuYVsMDs6d85f0w
Date: Tue, 05 Nov 2019 19:43:45 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01E709761F@marchand>
References: <156762274438.22762.9096288445438923152.idtracker@ietfa.amsl.com> <4F0F88D3-B973-49F2-92D8-64A291730F5A@ericsson.com>
In-Reply-To: <4F0F88D3-B973-49F2-92D8-64A291730F5A@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/hKOUsdeGOkiyxA-XmaLKMn4HI9I>
Subject: Re: [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
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: Tue, 05 Nov 2019 19:43:58 -0000
Hi Ari! Thanks for the pull requests and explanations below. My DISCUSS and COMMENTs are addressed by PR #13 and #14. Details inline ... > -----Original Message----- > From: Ari Keränen <ari.keranen@ericsson.com> > Sent: Sunday, November 03, 2019 6:04 PM > To: Roman Danyliw <rdd@cert.org>; The IESG <iesg@ietf.org> > Cc: draft-ietf-core-senml-etch@ietf.org; Carsten Bormann <cabo@tzi.org>; > core-chairs@ietf.org; core@ietf.org > Subject: Re: Roman Danyliw's Discuss on draft-ietf-core-senml-etch-05: (with > DISCUSS and COMMENT) > > Hi Roman, > > Thank you for your review! And apologies for late reply. Here's a PR to > address your comments: > https://github.com/core-wg/senml-etch/pull/13/files > > See comments and questions inline below. > > > Cheers, > Ari > > > On 4. Sep 2019, at 21.45, Roman Danyliw via Datatracker > <noreply@ietf.org> wrote: > > ---------------------------------------------------------------------- > > 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? > > Yes, secure CoAP would be addressing the security requirements in this case. > I can make this explicit by adding to the first paragraph: > > CoAP's security mechanisms are used to provide security for the FETCH and > (i)PATCH methods. Works for me. Thank you. > > (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. > > Yes, access control should be OK here. Do you have any suggestion how to > make this more clear here? Note that each SenML name may or may not > map to a separate resource (hence the wording "are actually part of (or > accessible through) the target resource"). I was stumbling over the "are actually part of ..." phrase. However, with your explanation, I understand now. My confusion. Consider this item resolved. > > > ---------------------------------------------------------------------- > > 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’)? > > Yes. I clarified this with: > > A Fetch Pack MUST contain at least one Fetch Record. A Fetch Record MUST > contain a name and/or base name field(s). Thank you. This text makes it clearer. > > 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? > > The intention was that only name and time could be used to select records; > the last paragraph says that all others must be ignored. But looking at this > closer I realized now that we probably need to add Unit to the selection > criteria to support cases where same sensor name is used with multiple units > for different types of measurements. > > But since this would be new functionality, I'll put this into a separate PR > (needs likely more work): > https://github.com/core-wg/senml- > etch/pull/14/files?utf8=%E2%9C%93&diff=split&w=1 OK. No problem. I wanted to highlight the issue. What you have in the above PR is mostly there. I leave it in your capable hands to polish. > > (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? > > Good catch. Clarified this with: > > If no SenML Records match, empty SenML Pack (i.e., array with no > elements) is returned as a response. Thanks. > > (5) Editorial Nits: > > > > -- Section 3.1. s/When SenML Records contain also time values/When > SenML > > Records also contain time values/ > > I realized this was not fully correct and rewrote that part into: > The SenML time field can be used in a Fetch Record to further narrow the > selection of matched SenML Records. Thanks. Regards, Roman
- [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