Re: [core] Short review of SenML fetch/patch

Ari Keränen <ari.keranen@ericsson.com> Thu, 27 September 2018 18:07 UTC

Return-Path: <ari.keranen@ericsson.com>
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 5B41D130EFB for <core@ietfa.amsl.com>; Thu, 27 Sep 2018 11:07:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.321
X-Spam-Level:
X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, 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=ericsson.com
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 QGw0lOfi6wiW for <core@ietfa.amsl.com>; Thu, 27 Sep 2018 11:07:31 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 243DE130EF7 for <core@ietf.org>; Thu, 27 Sep 2018 11:07:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1538071649; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=UIrzzetgCEaoNyEznJRRb9vxJG3iTchMlsPGI7UqpPk=; b=U9O2pSS/hFLpnQLQajE4QmjZT1NFql8mdbgVUMrJQiEhlJsqR7XcsmO6RfQA+XPd WcA9lypBKf94HtnTmghuhma8zS8UgkGiBFsBfz+ode3g4rPFhoHXcv088mUQ9k7z WeZUagGcylAr9VjZOsEZSN34m9RyyoIC9KPpYuup/vI=;
X-AuditID: c1b4fb25-8e7ff700000013ad-4f-5bad1c6163f2
Received: from ESESSMB505.ericsson.se (Unknown_Domain [153.88.183.123]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id EF.83.05037.16C1DAB5; Thu, 27 Sep 2018 20:07:29 +0200 (CEST)
Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 27 Sep 2018 20:07:28 +0200
Received: from ESESBMB502.ericsson.se ([153.88.183.185]) by ESESBMB502.ericsson.se ([153.88.183.185]) with mapi id 15.01.1466.003; Thu, 27 Sep 2018 20:07:28 +0200
From: =?utf-8?B?QXJpIEtlcsOkbmVu?= <ari.keranen@ericsson.com>
To: =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= <christian@amsuess.com>
CC: "draft-keranen-core-senml-fetch@ietf.org" <draft-keranen-core-senml-fetch@ietf.org>, core <core@ietf.org>
Thread-Topic: Short review of SenML fetch/patch
Thread-Index: AQHUVkB5+PFf3+Mfc0qMr/ag7hWmP6UES94A
Date: Thu, 27 Sep 2018 18:07:28 +0000
Message-ID: <8F814ABD-10B3-4279-945B-D1B33E0BD1A8@ericsson.com>
References: <20180927085947.GA5321@hephaistos.amsuess.com>
In-Reply-To: <20180927085947.GA5321@hephaistos.amsuess.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.153]
Content-Type: text/plain; charset="utf-8"
Content-ID: <93DFD51C666818478BC08A49496CA8B6@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEIsWRmVeSWpSXmKPExsUyM2J7tW6izNpog72N/Bb7dvSxWOx7u57Z 4k/HImYHZo+ug79YPZYs+ckUwBTFZZOSmpNZllqkb5fAldG9ah1bwQfzisMvHzE3MO4w62Lk 5JAQMJH4eq2frYuRi0NI4CijxKmNZ1lBEkIC3xglLvUrQ9jLGCVOPq4GsdkEbCWetO4DqxER cJDYdPYGM4jNLJAv8ffXeyYQW1hAT+LXzL9ANRxANfoS104GQ5QbSZy+9huslUVAVaLj5Bc2 EJtXwF5iwvHNUGutJNqPnmMEsTkFrCU67s9kB7EZBcQkvp9awwSxSlzi1pP5TBD3C0gs2XOe GcIWlXj5+B8rhK0ksffYdRaQE5gFNCXW79KHaLWWePdsI9TFihJTuh+yQ5wgKHFy5hOWCYzi s5BsmIXQPQtJ9ywk3bOQdC9gZF3FKFqcWpyUm25krJdalJlcXJyfp5eXWrKJERhzB7f8Vt3B ePmN4yFGAQ5GJR7elxxro4VYE8uKK3MPMUpwMCuJ8KpJAYV4UxIrq1KL8uOLSnNSiw8xSnOw KInzPjTfHCUkkJ5YkpqdmlqQWgSTZeLglGpgNNzVbPLpyZINnXcvxlf9frQheHNDz9Fvq72W hZd9jlhx7MP7TbMuyU3qMdb/7F5Vskl2JWtPX17w8429x5uEnk1zY725kVPfa+uv5tLYZWx7 hCvdKmz2n7ys/lb4meEz59RwiYd33payXQs/rVTSapqeO2GWYO2vHwXMJiXzGVp1dzZM33lU XImlOCPRUIu5qDgRABfcv9u1AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/Wos1MfO1xgTeqj92kKZ4gw1kFcA>
Subject: Re: [core] Short review of SenML fetch/patch
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: Thu, 27 Sep 2018 18:07:33 -0000

Thank you for the review Christian!

See inline.

> On 27 Sep 2018, at 11.59, Christian Amsüss <christian@amsuess.com> wrote:
> 
> Hello authors,
> 
> as requested during yesterday's interim meeting, I've had a look at
> senml-fetch again:
> 
> Fetch
> =====
> 
> Fetching by time
> ----------------
> 
> Being able to pick aparticular timestamp is an oddly specific
> application; my impression of general SenML data sets is that it will be
> hard to predict which point in time should have a datum if that record
> is not already known. Unless there are good (and argued for) use cases,
> I suggest that the topic of fetching time series points be explored
> comprehensively in a separate document, possibly hooking into
> draft-bormann-t2trg-stp.

The time-stamp use case I had in mind was where the record is already known, so it's mainly useful for PATCHing, but didn't see issue having it for FETCH too (say, you know time out of band). Otherwise we have no mechanism to tell apart two records from the same source.


> Using SenML to fetch
> --------------------
> 
> SenML requires to have a value (or sum) on every record, the payload of
> the fetch request therefore can't use any of the defined SenML mime
> types but would need to specify their own. I'm unsure on whether adding
> a field like "fetch_":1 to the first record (a mandatory-to-decode
> custom field) would be sufficient to work around that constraint.
> 
> Otherwise, it might be an option to update RFC8428 to say that some of
> those limitations (also the later "v":null) may be overridden in
> applications like this where it is made sure (eg. by never using those
> freedoms in Content or PUT payloads) that no generic SenML processor
> ever gets its hands on the document.

Good point. Maybe updating 8428 with the exception that restrictions on value don't apply for FETCH/PATCH is appropriate.

> The payload sent in as a FETCH payload is not actually sensor data, it's
> a list of names (or, provided they're viewed as URIs, which I recommend)
> links. We already have a way to transmit a list of links in CoRE
> (actually 3 with links-json). I don't object to introducing another
> (given the above, might be called application/links+senml+{cbor,json}?)
> especially to reduce parsing complexity, but do suggest that FETCHing
> SenML data be done with a list of identifiers no matter how they are
> transported, and the recommended way can well be a SenML-names-only
> payload (but would not preclude others).

The payload is a list of names without URI semantics (e.g., may not have scheme at all, have different concatenation semantics, etc.) and timestamps, so I think it's quite different from the other link formats.

> Patch
> =====
> 
> "value field with value null": There has been some backpressure against
> having variable-type fields in SenML back when its JSON/CBOR structure
> was last changed; having a "v":null in there could be problematic (esp.
> as its JSON type is fixed to Number in Table 2 of RFC8428). I suggest
> having a explicit "delete value" field, eg. "vdel":true.

The "v":null approach made this nice and clean, but you do have a valid point to consider here. Will have a closer look at this.

> How would base values work with patch? I figure that it's always the
> resolved record that matter, but that should be explicit. In connection
> with a "vdel" (or "v":null if it turns out it's OK for it to stay like
> that), it might make sense to allow that too (where a "v":n would
> override "vdel" or "v":null from an offset of zero) to allow for
> efficient batch removal of values.

Yes, resolved records are that matter (see end of section 3.1). I'm not quite sure what you suggest allowing though?

> Security considerations
> =======================
> 
> "potentially allow retrieving or changing many resources at once" makes
> it sound like FETCH and PATCH could reach out to different resources.
> They don't (conceptually), they only manipulate what's inside the target
> resource (which typically is an aggregation of other resources, as in a
> core-interfaces batch). Suggested replacement:
> 
>   In FETCH and iPATCH 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.
> 
>   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.
> 
> (It's fine if someone goes ahead and defines a /senml resource on their
> device that is a gate to "everything and anything that can be addressed
> in SenML", but that shouldn't be the default assumption).

Good point. The replacement looks good to me.


Thanks,
Ari

> Best regards
> Christian
> 
> -- 
> You don't become great by trying to be great. You become great by
> wanting to do something, and then doing it so hard that you become great
> in the process.
>  -- Marie Curie (as quoted by Randall Munroe)