Re: [Iotsi] New IoT effort at schema.org

Tim Coote <tim+ietf.org@coote.org> Tue, 23 August 2016 11:26 UTC

Return-Path: <tim+ietf.org@coote.org>
X-Original-To: iotsi@ietfa.amsl.com
Delivered-To: iotsi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD2D126579 for <iotsi@ietfa.amsl.com>; Tue, 23 Aug 2016 04:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=coote.org header.b=IYGK2XQ3; dkim=pass (1024-bit key) header.d=coote.org header.b=dy1ixRSG
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 gwiE1zSWd5Az for <iotsi@ietfa.amsl.com>; Tue, 23 Aug 2016 04:26:41 -0700 (PDT)
Received: from mercury.coote.org (575185b4.skybroadband.com [87.81.133.180]) by ietfa.amsl.com (Postfix) with ESMTP id 7200312B011 for <iotsi@iab.org>; Tue, 23 Aug 2016 04:26:40 -0700 (PDT)
Received: by mercury.coote.org (Postfix, from userid 1000) id 9E8BE16C1329; Tue, 23 Aug 2016 12:26:38 +0100 (BST)
DKIM-Filter: OpenDKIM Filter v2.10.3 mercury.coote.org 9E8BE16C1329
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=coote.org; s=default; t=1471951598; bh=oaPGj9NXdQtyYQkT2KQKFx+X/yY2nCx8I6op7vNYYOc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=IYGK2XQ31Lvcyb8A+rb3VbUnuegPsV1acFPVilvdH4eLZSXS+5nDUeZpbR5g7ylmv f/sUpDIaKUsgAnwXjqQXuQjciOr4VXkQcaP4a+l/kq6Neb4JO1Z7TNxNSdrgFEyoFm /jyNwPTTAtNXP/97AtT7+Hx9+3ueHh5C9nOTmcrg=
X-Original-To: iotsi@iab.org
Received: from [127.0.0.1] (localhost [IPv6:::1]) by mercury.coote.org (Postfix) with ESMTP id 7CAB116C1137; Tue, 23 Aug 2016 12:26:37 +0100 (BST)
DKIM-Filter: OpenDKIM Filter v2.10.3 mercury.coote.org 7CAB116C1137
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=coote.org; s=default; t=1471951597; bh=oaPGj9NXdQtyYQkT2KQKFx+X/yY2nCx8I6op7vNYYOc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=dy1ixRSGHHgXgZHGy5733CepDUOJ6cUEIxJHKmNZ3hgasMHGvnap05AVC5XVQbhPN ldDYtzmYe4Mt+QICccqrjSLFqPE/xG4l9D2QyeQEcZ0I8RmhmEOnS6/GpB5lTyEc68 XL8nxYvrbMUti+IH9ieEl12hdl2yV5Y8mFDeHnZg=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Tim Coote <tim+ietf.org@coote.org>
In-Reply-To: <56171746-364d-ec04-44b9-78068f50e6c1@cisco.com>
Date: Tue, 23 Aug 2016 12:26:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <49919A41-7CDA-4515-8509-8A93DD11F97B@coote.org>
References: <CA+9kkMCRY6eRF+FgSAm2yE_HdH3i90WYCwxVCUaWM-Drk3kvgQ@mail.gmail.com> <CACp1KyPDYkKcK0u0XZOMbCMQWtyOuR2nnv4w1HMAMTopMVyZew@mail.gmail.com> <ACC85CBE-A2A8-4813-91B5-F8E6F7D409AD@coote.org> <a574ca33-8053-ba9a-443b-fb15234f5c51@cisco.com> <HE1PR0802MB2475ED419A0DD913BCA2DD15FAEB0@HE1PR0802MB2475.eurprd08.prod.outlook.com> <56171746-364d-ec04-44b9-78068f50e6c1@cisco.com>
To: Eliot Lear <lear@cisco.com>
X-Mailer: Apple Mail (2.2104)
X-Spambayes-Classification: ham; 0.00
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotsi/boJ-lAf029rmDCoRP32nAXtTTgg>
Cc: "iotsi@iab.org" <iotsi@iab.org>, David Janes <davidjanes@davidjanes.com>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Ted Hardie <ted.ietf@gmail.com>, Internet Architecture Board <iab@iab.org>
Subject: Re: [Iotsi] New IoT effort at schema.org
X-BeenThere: iotsi@iab.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Internet of Things Semantic Interoperability Workshop <iotsi.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/iotsi>, <mailto:iotsi-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iotsi/>
List-Post: <mailto:iotsi@iab.org>
List-Help: <mailto:iotsi-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/iotsi>, <mailto:iotsi-request@iab.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Aug 2016 11:26:42 -0000

Hullo

I’ll write up a simple example later today to illustrate the sorts of issues that I’m trying to describe.
> On 23 Aug 2016, at 12:06, Eliot Lear <lear@cisco.com>; wrote:
> 
> Hi Hannes,
> 
> 
> On 8/23/16 12:56 PM, Hannes Tschofenig wrote:
>> Eliot, Tim,
>> 
>> I believe you are talking about two different types of states.
>> Is my understanding correct? Tim, maybe you can elaborate a bit more about the ' overall system state' you are referring to.
> 
> Tim wrote:
>> However, there is a significant issue that the deployed Things do not
>> necessarily tell (or know) the truth about what they are or their
>> current state.
> 
> It's the "who they are" part below that I'm working on now.  That's what
> MUD+802.1AR gives you.  In that case, as I wrote, the assertion is from
> the manufacturer of the Thing, and not the Thing itself.  As to the
> device's operational state, that gets us into other areas that is not
> unique to Things, and leads us toward the age old question: “how do you
> know whether a device is sane or has been hacked?”  And there are ways
> to address that, imperfect though they may be.
> 
> Eliot
> 
> 
There’s a commercial asymmetry here, which means that Thing Makers may not know what they have released (their focus is on shifting boxes) and any assertion, unless backed up by a legal contract is worth little. Whoever is dropping in hardware based Things may put in a new version or a replacement from a different supplier that claims to be the same as something else. But isn’t. 

My conclusion was that the owner of the service delivered to the customer must define automated tests and behaviour categorisations that are used to accept new components and to identify rogues in production. Testing Hardware Things should have the same sorts of dependency injection as is common in s/w test approaches. Any uncertainty of what’s in the overall configuration needs to be flagged to relevant users as soon as it is identified.

Although ‘is a device sane’ is an old problem, IoT types of systems have many more degrees of freedom than traditional areas where this question has arisen and the markets are being addressed by firms with varying engineering capabilities. I have seen Things where a firmware bump was a/ not identifed by the Thing and b/ caused a failure on Thursday’s with specific configuration combinations.

tc