[smartpowerdir] question on identification of sensors

Jari Arkko <jari.arkko@piuha.net> Wed, 28 July 2010 18:32 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: smartpowerdir@core3.amsl.com
Delivered-To: smartpowerdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 2483B3A693E for <smartpowerdir@core3.amsl.com>; Wed, 28 Jul 2010 11:32:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.42
X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[AWL=-0.680, BAYES_20=-0.74]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id cpY+YGo08gJS for <smartpowerdir@core3.amsl.com>; Wed, 28 Jul 2010 11:32:38 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id D5F193A6ACA for <smartpowerdir@ietf.org>; Wed, 28 Jul 2010 11:32:37 -0700 (PDT)
Received: from localhost (localhost []) by p130.piuha.net (Postfix) with ESMTP id 2273F2CED6; Wed, 28 Jul 2010 21:33:00 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([]) by localhost (p130.piuha.net []) (amavisd-new, port 10024) with ESMTP id eUpd2lDO2bni; Wed, 28 Jul 2010 21:32:55 +0300 (EEST)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 782A42CC62; Wed, 28 Jul 2010 21:32:55 +0300 (EEST)
Message-ID: <4C5077D7.8010205@piuha.net>
Date: Wed, 28 Jul 2010 20:32:55 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird (X11/20100411)
MIME-Version: 1.0
To: IETF SmartPower Directorate <smartpowerdir@ietf.org>, Cullen Jennings <fluffy@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [smartpowerdir] question on identification of sensors
X-BeenThere: smartpowerdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Members of the Smart Power Directorate <smartpowerdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/smartpowerdir>, <mailto:smartpowerdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smartpowerdir>
List-Post: <mailto:smartpowerdir@ietf.org>
List-Help: <mailto:smartpowerdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smartpowerdir>, <mailto:smartpowerdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Jul 2010 18:32:40 -0000

I have a practical question for the directorate. The question relates to 
what I'm doing as a hobbyist in my own sensor networking, but I think 
its also a wider question that would have importance for others.

My sensors have identities. They may or may not have (stable) network 
layer addresses or DNS names. In some cases a sensor might get different 
addresses at different times (movement), not exist as an IP host but as 
a legacy device behind a gateway, or a single IP host might be able to 
make a number of measurements (temperature, location, humidity). 
Information from the sensors gets processed in various ways, including 
filtering by servers, archival storage, application layer routing for 
the interested consumers, etc. In my mind, all of these factors speak in 
favor of identifying sensors or "things" in application layer data. As 
part of some XML structure sent somewhere, in a log file, and so on.

My question relates to whether we need ways to represent "thing" 
identities in URNs. To make the question more concrete, I'm running a 
bunch of sensors that have either 64-bit 1-wire hardware identifiers or 
Ethernet MAC addresses. I would like to have an identifier format that I 
can stick to different places with a consistent syntax. However, there 
is no way to represent MAC addresses or other hardware in URNs at the 
moment, AFAIK. The question is, would adding such identifiers in the URN 
space make sense from an architectural perspective? If I google for some 
old discussions around supporting MAC addresses in URNs I find flame 
wars. So as an IP guy I plead some assistance from the group, hoping 
that you have more understanding of the application layer constructors 
and appropriate designs there.