Re: [Iotsi] New IoT effort at

Tim Coote <> Tue, 23 August 2016 11:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FD2D126579 for <>; Tue, 23 Aug 2016 04:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (1024-bit key) header.b=IYGK2XQ3; dkim=pass (1024-bit key) header.b=dy1ixRSG
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gwiE1zSWd5Az for <>; Tue, 23 Aug 2016 04:26:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7200312B011 for <>; Tue, 23 Aug 2016 04:26:40 -0700 (PDT)
Received: by (Postfix, from userid 1000) id 9E8BE16C1329; Tue, 23 Aug 2016 12:26:38 +0100 (BST)
DKIM-Filter: OpenDKIM Filter v2.10.3 9E8BE16C1329
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; 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=
Received: from [] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 7CAB116C1137; Tue, 23 Aug 2016 12:26:37 +0100 (BST)
DKIM-Filter: OpenDKIM Filter v2.10.3 7CAB116C1137
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; 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 <>
In-Reply-To: <>
Date: Tue, 23 Aug 2016 12:26:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Eliot Lear <>
X-Mailer: Apple Mail (2.2104)
X-Spambayes-Classification: ham; 0.00
Archived-At: <>
Cc: "" <>, David Janes <>, Hannes Tschofenig <>, Ted Hardie <>, Internet Architecture Board <>
Subject: Re: [Iotsi] New IoT effort at
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Internet of Things Semantic Interoperability Workshop <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Aug 2016 11:26:42 -0000


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 <>; 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.