Re: [core] Roman Danyliw's Discuss on draft-ietf-core-senml-etch-05: (with DISCUSS and COMMENT)

Ari Keränen <> Wed, 06 November 2019 20:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E95251200FE; Wed, 6 Nov 2019 12:43:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uYtNZqJLap4n; Wed, 6 Nov 2019 12:43:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8D81E1200F4; Wed, 6 Nov 2019 12:43:44 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=SFG3KMrHf8F5XH3AcVlPz3+YR1tyjZ91q5DIJMpff8NALsToifhZI1o7eXnyvJ51AXyrVAQ1caAo383gumrTaQOdgARBSmktNpqpcw6FXTHmLem1PEP9kXZ9oyeVYBG/NFOqCGGTY7YDLKlEBPdzLbRKfU0sWCMPqljE+yrMYv2mQPh+oMMF1HTA9eVWRTOpUhZmRPAfFNSNV9q+GZuEenV3Q7OJ+QfIsOGyL7YrZ9E+Y5hlh+LRrKNX7BhLW6ydZLpmUrGELrUMS/VQsnWBvOr3+ZCfz93A+TqPJfs+SS+knxqeOjt+PSjG6UOBdDzENYKxOYgFLnWyIO5Aa2XwpQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sVJloX96+0XJ5k5EEwMTjDphyIi7OK7l3FhssiHMRGM=; b=UaTLFGdAy4U/fBd2XXBRuZaihCmXM6XMTpytNtnhgkpEg9UTMiDun5J6FZtrTFij8oBG9CpddOABp2LttUiOeCUPiIN3NjgSszoP1CwUrSCHZiWTLD3GYLYxMRt++f3WcYJ2fW5fQsq8C+jR2Uo61HrdSh2UNT0cm7PCQk0x6EjhQeEyeqL5HuhXD6kVKmhi/Vypf4qIb1QmeGi3+wV9KT5aaZclC0zRvSj7faCH0ljiG77f4IfrBgIZnu6dw0a0SPFRHM7mzWCuCXoRev/Cirw4Hy8tziQjEhw7f9XZIwABEcqbpzQ9cbgTml0H/qNFyGwauQAmz2hecVpjRP9nCw==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sVJloX96+0XJ5k5EEwMTjDphyIi7OK7l3FhssiHMRGM=; b=CHRPQLo/SKIWXEbKwNvDAksjswfrdgBIydThMTOsT+tC/regr5zz30YqZvexfYZlU5mwPfRUaUEYvPyoUpfKs87aUA/1A0jd0Xq4Ya6I5IZSPUOQIZtbBY6m+F8Nn/BEsbJppAcR+EDk7WuLUcLmY5H6OMu+Mo/MjagJJNzGxCw=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.16; Wed, 6 Nov 2019 20:43:42 +0000
Received: from ([fe80::4d7a:2832:2938:f3a1]) by ([fe80::4d7a:2832:2938:f3a1%4]) with mapi id 15.20.2430.014; Wed, 6 Nov 2019 20:43:42 +0000
From: =?utf-8?B?QXJpIEtlcsOkbmVu?= <>
To: Roman Danyliw <>
CC: The IESG <>, "" <>, Carsten Bormann <>, "" <>, "" <>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-core-senml-etch-05: (with DISCUSS and COMMENT)
Thread-Index: AQHVY1D7tA+HnVveGEq7E6ao1Arl6qd6Td4AgAMOK4CAAaImAA==
Date: Wed, 6 Nov 2019 20:43:41 +0000
Message-ID: <>
References: <359EC4B99E040048A7131E0F4E113AFC01E709761F@marchand>
Accept-Language: en-US
Content-Language: en-GB
user-agent: Microsoft-MacOutlook/10.1d.0.190908
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:14bb:150:480b:e497:74d6:5b54:49b3]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fa332163-3221-496a-4054-08d762fa0299
x-ms-traffictypediagnostic: VI1PR07MB5741:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-forefront-prvs: 02135EB356
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(39860400002)(396003)(136003)(366004)(189003)(199004)(13464003)(51914003)(446003)(58126008)(478600001)(66476007)(256004)(316002)(66574012)(85202003)(33656002)(36756003)(71190400001)(6506007)(71200400001)(99286004)(53546011)(6486002)(86362001)(14444005)(186003)(8936002)(6246003)(81156014)(81166006)(2906002)(102836004)(76176011)(486006)(476003)(966005)(6512007)(46003)(8676002)(54906003)(4326008)(14454004)(7736002)(6116002)(305945005)(6916009)(2616005)(85182001)(6436002)(5660300002)(6306002)(91956017)(76116006)(66946007)(64756008)(25786009)(66446008)(66556008)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB5741;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: IBFxyuoiv87FQtjMidYKaEKfN4apRMoBZJLR5LMDIDTlhFj1xiTxBJOyLaZO+ShdCu2Z0No35UXCeUN/5dvUwO6i2uHUetu4XAsSLY0CWxzvP9CVFnpPYP36/gaoZAB2QF/1z0x26kkGSk4yOi482YnfCs6+E1IHGHp75rskxE66ctSHQ9qYabFqSgk5Ly8jS8tM1nF0nuR9R4TNb/pMEGcLDasJtCOu8BTyDB0nC+AeC39Qhc9/xEz6Cd+Akww6MqAgHTmmiFisiOouUEQwnBSml+X5mWtz7sR7sqB5oFCFNlGT7L2eXBpOvKtJhk+Dg4K5YMJco2hsqLZo0hXPoKKodGEymy56O9XvdqV0zgXsYUqwLd/Bd34h7WhxtgoouojP3tSkVaP31tlqG0ksBdM/G1wH6Oi/hCR/3me2BNrFRV6RRYUTPqX+VSuoPmbI/XV+1HoLbOZP/O9hWSa9bo5akzBmo4W1gKyXOwhy+Ao=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: fa332163-3221-496a-4054-08d762fa0299
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 20:43:41.9849 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: FpH96sIrrLhT5RLYd1qYYKou9xmvP57x67cm67vdbxCRVYHVeaZiBemVH2BUQySnKRyA2O5O4fYH3dX5X4CWBiUf2oIfQBiaOWqX4k6zzsM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5741
Archived-At: <>
Subject: Re: [core] Roman Danyliw's Discuss on draft-ietf-core-senml-etch-05: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Nov 2019 20:43:48 -0000

Thank you Roman!

I merged now PR 13 so that it will be part of the next draft version. We'll still take a closer look at #14.


> On 5. Nov 2019, at 21.44, Roman Danyliw <> wrote:
> 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 <>
>> Sent: Sunday, November 03, 2019 6:04 PM
>> To: Roman Danyliw <>rg>; The IESG <>
>> Cc:; Carsten Bormann <>rg>;
>> Subject: Re: Roman Danyliw's Discuss on draft-ietf-core-senml-etch-05: (with
>> Hi Roman,
>> Thank you for your review! And apologies for late reply. Here's a PR to
>> address your comments:
>> See comments and questions inline below.
>> Cheers,
>> Ari
>>> On 4. Sep 2019, at 21.45, Roman Danyliw via Datatracker
>> <> wrote:
>>> ----------------------------------------------------------------------
>>> ----------------------------------------------------------------------
>>> (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.
>>> ----------------------------------------------------------------------
>>> ----------------------------------------------------------------------
>>> (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):
> 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