Re: [6lowpan] SOLACE things at SAAG

Carsten Bormann <> Mon, 29 October 2012 21:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D83AD21F86E7; Mon, 29 Oct 2012 14:16:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -107.337
X-Spam-Status: No, score=-107.337 tagged_above=-999 required=5 tests=[AWL=-1.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p-OZ9WrV6y4B; Mon, 29 Oct 2012 14:16:32 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:30c9::12]) by (Postfix) with ESMTP id ED9D721F86E1; Mon, 29 Oct 2012 14:16:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id q9TLFdsf029404; Mon, 29 Oct 2012 22:15:39 +0100 (CET)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 5B04D194; Mon, 29 Oct 2012 22:15:38 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Content-Type: text/plain; charset="iso-8859-1"
From: Carsten Bormann <>
In-Reply-To: <>
Date: Mon, 29 Oct 2012 22:15:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <015901cdb0d3$d38cf1f0$7aa6d5d0$> <> <> <02a101cdb5f5$51109a70$f331cf50$> <> <> <> <>
To: Stephen Farrell <>
X-Mailer: Apple Mail (2.1499)
Cc: Cullen Jennings <>, Michael Richardson <>,, "'Keoh, Sye Loong'" <>,, "Turner, Sean P." <>,
Subject: Re: [6lowpan] SOLACE things at SAAG
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Working group discussion for IPv6 over LowPan networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Oct 2012 21:16:33 -0000

On Oct 29, 2012, at 21:45, Stephen Farrell <> wrote:

> If he and Cullen want to arm-wrestle
> that's fine:-)

Well, Cullen's I-D (please have a look at draft-jennings-core-transitive-trust-enrollment-01.txt,.pdf)
is a very good example for the kind of input document that we are looking for.

But it is just one way of doing things.  There are so many others.  To a large extent, the differences are not just based on technological choices, but on what people are actually trying to do with the smart objects, i.e., what purpose in life they have.

After half a decade of kicking around half-baked solutions in this space in various IETF working groups, I think it is a good idea to spend more time understanding the design space.  How, and where, to spend this time in the most productive way is what I would like to discuss with interested people before we do the SAAG slot: ->

Grüße, Carsten

PS. Here is section 3.3 of the CoRE roadmap I-D, which lists a couple more related drafts:

   Several individual drafts analyze the issues around the security of
   constrained devices in constrained networks.

  | draft-garcia-core-security                      |     | 2012-03-26 |
  | draft-sarikaya-core-sbootstrapping              | -05 | 2012-07-10 |
  | draft-jennings-core-transitive-trust-enrollment | -01 | 2012-10-13 |

   [I-D.garcia-core-security] in particular describes the "Thing
   Lifecycle" and discusses resulting architectural considerations.
   [I-D.jennings-core-transitive-trust-enrollment] demonstrates a
   specific approach to securing the Thing Lifecycle based on defined
   roles of security players, including a Manufacturer, an Introducer,
   and a Transfer Agent.

   Further work around Thing Lifecycles is also expected to occur in the
   SOLACE initiative (Smart Object Lifecycle Architecture for
   Constrained Environments), with its early mailing list at -- developed after the model of the COMAN initiative
   (Management for Constrained Management Networks and Devices,, [I-D.ersue-constrained-mgmt]).