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

[Tim Coote <[e-mail]>]

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 <[e-mail]> 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