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

[Eliot Lear <[e-mail]>]

Hi Tim,

I'm responding to both this and your other message.


On 8/23/16 1:26 PM, Tim Coote wrote:
> 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. 

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.

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?


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

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.

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

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.

Eliot