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: =?utf-8?B?QXJpIEtlcsOkbmVu?= <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, 5 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>rg>; The IESG <iesg@ietf.org>
> Cc: draft-ietf-core-senml-etch@ietf.org; Carsten Bormann <cabo@tzi.org>rg>;
> 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