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

Eliot Lear <lear@cisco.com> Thu, 01 September 2016 06:32 UTC

Return-Path: <lear@cisco.com>
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 28E6612B061; Wed, 31 Aug 2016 23:32:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.069
X-Spam-Level:
X-Spam-Status: No, score=-15.069 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 zHNN76kbcvgK; Wed, 31 Aug 2016 23:32:46 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77F912B037; Wed, 31 Aug 2016 23:32:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10987; q=dns/txt; s=iport; t=1472711566; x=1473921166; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=+2KoG70l1uxqBkKJ6YTS3ucCD62/BmXC9cOkB6Ld9Ck=; b=Lh/Hdk08Xx54WXpRffG51l/lrGwwkjpHQKElfRWnLg4RUa+GVFEkj5RX VYPEia4C0GT8NWhQZaQralYABxVK726kKQ2xjAy8pb9JAK9FpQvdQfgIl 1OXKZG6C9XgSq9hderxyhT2ZQTmbV36S00cI69IyoSEikfRCr45X9LYuH U=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ClDwADy8dX/xbLJq1TCoNQAQEBAQF1K?= =?us-ascii?q?lKzG4UNggEchgACggITAQIBAQEBAQEBXieEYQEBBAEjVhALGCoCAlcGDQgBAYg?= =?us-ascii?q?8CK4cjGwBAQEBAQEBAQEBAQEBAQEBAQEBAQEODognglWEGIMqgloBBJlQgz6Bc?= =?us-ascii?q?2+JEYI7hyCFfIRLi3YgAjKEMzo0hmwBAQE?=
X-IronPort-AV: E=Sophos;i="5.30,265,1470700800"; d="asc'?scan'208,217";a="644802083"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Sep 2016 06:32:43 +0000
Received: from [10.61.209.230] ([10.61.209.230]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u816WhSm021529; Thu, 1 Sep 2016 06:32:43 GMT
To: Tim Coote <tim+ietf.org@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> <49919A41-7CDA-4515-8509-8A93DD11F97B@coote.org>
From: Eliot Lear <lear@cisco.com>
Message-ID: <27ef5545-8b4f-a79f-9efc-2378cec1e61b@cisco.com>
Date: Thu, 1 Sep 2016 08:32:45 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <49919A41-7CDA-4515-8509-8A93DD11F97B@coote.org>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lqekLnpmAeTBH7IaG9uXWNl9hX3UmBhL5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/iotsi/5T9X02ka0_E0BGzbkkXeL81z_Kg>
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: Thu, 01 Sep 2016 06:32:48 -0000

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