Re: [Iotsi] New IoT effort at

Tim Coote <> Thu, 01 September 2016 09:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D24D12D112 for <>; Thu, 1 Sep 2016 02:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key) header.b=owo3O9IA; dkim=pass (1024-bit key) header.b=h0HOBFHF
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ndqKOK9QfY0L for <>; Thu, 1 Sep 2016 02:45:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5999812D882 for <>; Thu, 1 Sep 2016 02:45:56 -0700 (PDT)
Received: by (Postfix, from userid 1000) id 9728016C138A; Thu, 1 Sep 2016 10:45:22 +0100 (BST)
DKIM-Filter: OpenDKIM Filter v2.10.3 9728016C138A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1472723122; bh=BDrAqtz+YArumeYvtWVEtGSqnZQTDJblO6v5PKXM9Vs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=owo3O9IAxA32Uz3SIJWWUMFl0C3O8p1tIg4Txx+r4HreGByWv04oDL7DUvipW1XI6 CN8N4mfKtFoW/zSTRn9GGvBVxmxKvK278aQnlhm6kcwbGJKopYn53Vl7KBQ56ht0UM vrOY8pZKWSM4aEQw/hz/3kiwkt4Faj5bW8DYesmg=
Received: from [] (localhost [IPv6:::1]) by (Postfix) with ESMTP id E83CD16C106D; Thu, 1 Sep 2016 10:45:20 +0100 (BST)
DKIM-Filter: OpenDKIM Filter v2.10.3 E83CD16C106D
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1472723121; bh=BDrAqtz+YArumeYvtWVEtGSqnZQTDJblO6v5PKXM9Vs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=h0HOBFHFcm+hg4FvXspd69SbSvXs0hGHDyjx108P3wyRL4PkXwgZXZla650zql9Fu I7s3l2fzJV5sr7F/VR7jGFd6WxTZZ0yqNcbnHw98ghuT3GJ2q3cRwmpBakuL07f+RX DHo8uoMcvjziWWJqlXUFXn71RO8E2Tzkh2O6BtdE=
Content-Type: multipart/alternative; boundary="Apple-Mail=_C000951B-1541-429D-9E5A-E461808D627D"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Tim Coote <>
In-Reply-To: <>
Date: Thu, 1 Sep 2016 10:45:20 +0100
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: Thu, 01 Sep 2016 09:45:59 -0000

Hi Eliot
Quick top post, and thanks for the point of view.

From the SI pov, the problem is much more complex as they do not have visibility of what’s being integrated. SIs do understand how to do this type of integration for software, but they and the device makers seem to be unaware of each other’s world. My conclusion was that the SIs need to get control and impose decent testability on the device makers - but that’s not where the market is at the moment.
> Hi Tim,
> I'm responding to both this and your other message.
> On 8/23/16 1:26 PM, Tim Coote wrote:
> [snip]
> You are raising two issues:
> One is the old “I'm a Vendor X inkjet cartridge” problem.  As we have seen in the market, Vendor X has an incentive to prevent counterfeiting.  IEEE 802.1AR provides the standards basis to address that very problem.
> The second issue is the old “I am a VT100” trick, which is also the less old “I am browser X” trick, done not so much to counterfeit, but to indicate compatibility and interoperability.
I believe that IoT is not like these examples, where what has changed is obvious and visible to all as there is only one integration point to an entity with a well-defined behaviour that uses a robust control layer. I think that the issue is that the different architectural layers in IoT cannot rely on those below them.
> These two are related.  In a business sense, a vendor has an incentive to see that only published interfaces are used, so that they can make changes to private interfaces.  From a vendor perspective typically they will publish interfaces for the components they don't want to build, themselves.  That includes integration with other control systems.  In the example you gave in the other message of a heating control system, that might be the temperature sensor if the margins are sufficiently low, but playing against that are service assurance concerns.  Systems integrators can step into that market if it is what the vendor wishes/needs.  At that point it will be the SIs who do the testing.  That's their value add.  For less critical systems there are certification systems such as the WiFi Alliance (as an example) and CableLabs.  We will see IoT versions of those, I'm sure, for the consumer space, but they may be granular.  The one that has bedeviled consumers has been the entertainment system remote control.  Various HDMI standards provide for some integration, but who among us has but one remote control?
I don’t think that some of these failure modes are testable a priori. The point about the remote control is a good one, that may highlight my concern as the remote is a single point of integration. The failures that I’ve seen seem to be transitive: devices work in isolation, but collectively fail.
> [snip]
> If the SIs from above want to do that testing, then a mechanism like NEA may be helpful, and it may even be desirable from a vendor perspective if they want to open interfaces and address service assurance.  But I think it has to be combined with 802.1AR or something similar.  That provides for some accountability as well as some limits: if it's counterfeit the vendor can wash his hands of the matter or better yet make a sale.
I’m goint read NEA. Thanks for the pointer.
> [snip]
> Yes, and I would say that the market is highly immature.  A good thing.  It means there's lots of room for growth and development of approaches.
Indeed. But also more risk of bad press as there are already systems being built that are not fit for purpose. A simple example: ZWave emerged from the remote control model, where the user can see the device she’s interacting with. So, you get the ‘multi-remote-control’ problem as, say, ZWave devices can talk ZWave to each other. But also, the unobserved usecases are missing: a ZWave lock can tell you whether it is locked, but not whether the lock as locked the door (as opposed to being locked-open).  Maybe there’s just a bunch of pain for consumer facing IoT to go through. 
> Eliot