Subject: [apps-discuss] Device URNs

From: Jari Arkko <[email-masked]>
Date: Thu, 23 Feb 2012 15:30:04 +0200

Hi,

We'd like to get some feedback on a draft that we wrote a while ago, on identifying devices. The basic idea is a definition of a new URN type, e.g., "urn:dev:mac:0024befffe804ff1" that can use hardware identifiers such as MAC addresses or 1-wire identifiers. The authors have been using identifiers of this type as identifiers in data streams coming out of very simple devices that lack any configuration or even the capability to be configured. For instance, a sensor that is measuring something produces a stream of measurement messages, identifying itself with its hardware address. The information is collected to a database somewhere in the network, and that database can correlate things like "urn:dev:ow:10e2073a01080063" meaning the sensor in Jari's kitchen. There are also other possible use cases, equipment catalogs, for instance.

http://tools.ietf.org/html/draft-arkko-core-dev-urn-01

The draft has three different address types currently, but the list could be changed. For instance, we know that the third variant, cryptographic identifiers, is not strictly speaking aligned with current requirements on what URNs must satisfy, as cryptographic identifiers have only statistical, not administered uniqueness.

Thoughts? Good idea? Bad idea? Improvement suggestions? Other things* we should use instead?

Jari

*) The draft has some discussion of why we feel UUIDs are not suitable in all cases.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 23 Feb 2012 11:30:52 -0700

On 2/23/12 6:30 AM, Jari Arkko wrote:

> we know that the third variant,
> cryptographic identifiers, is not strictly speaking aligned with current
> requirements on what URNs must satisfy, as cryptographic identifiers
> have only statistical, not administered uniqueness.

Jari, in what respect is that different from UUIDs (RFC 4422)? Neither
has administered uniqueness, but folks on the [email-masked] list
convinced me last year that urn:uuid is perfectly acceptable; see the
thread starting here:

http://www.ietf.org/mail-archive/web/urn/current/msg01612.html

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 23 Feb 2012 11:31:58 -0700

On 2/23/12 11:30 AM, Peter Saint-Andre wrote:
> Jari, in what respect is that different from UUIDs (RFC 4422)? 

RFC 4122, that is:

http://tools.ietf.org/html/rfc4122

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Jari Arkko <[email-masked]>
Date: Thu, 23 Feb 2012 21:39:39 +0200

Peter,

First, it looks like I should have posted to the URN list (I did not remember one existed... shows how much I know :-)

In any case, here's what the draft says about UUIDs:

    Universally Unique IDentifier (UUID) URNs [RFC4122] are another
    alternative way for representing device identifiers, and already
    support MAC addresses as one of type of an identifier.  However,
    UUIDs can be inconvenient in environments where it is important that
    the identifiers are as simple as possible and where additional
    requirements on stable storage, real-time clocks, and identifier
    length can be prohibitive.  UUID-based identifiers are recommended
    for all general purpose uses when MAC addresses are available as
    identifiers.  The device URN defined in this memo is recommended for
    constrained environments.

But to put this into more concrete terms, I have a problem with the way the UUID RFC requires me to handle time. I could be reading the RFC wrong; I'd be happy to be corrected.

The first problem is that it requires the existence of a clock and in practice requires the existence of stable storage, which may not exist on all types of platforms. But perhaps those issues are solvable. The more serious practical problem is that I want to use devices manufactured with standard hardware identifiers, which I can note at the time of manufacturing and then correlate that information with the whatever the message the device is sending later. For instance, device HW address is printed on the box, I install the device somewhere, when I get a message from the device later I'll know that it came from that particular "somewhere". If the device needs to boot up and generate a UUID with random or time-dependent components, this matching is harder.

I think there are ways around these things with UUIDs. You could manufacture devices with UUIDs burned into them and print them on the box. But that would set a requirement on them that current devices and manufacturing processes do not have. If I want to use off-the-shelf tiny ethernet-based sensor platforms they don't come with UUIDs burned in. (And while I'm mostly representing myself with these requirements, they seem pretty common when I talk to various industry players. We have a large we-manage-your-iot-devices-for-you business at my day job; those folks very much want to see a model where you never have to touch, configure, power up, or boot the device in any way before it is put out there in the field. All the intelligence about what devices does what is in the servers somewhere.)

But I could be missing something, of course.

Jari

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 23 Feb 2012 13:42:13 -0700

> But I could be missing something, of course.

I think you were missing the point of my message: that administered
uniqueness is not necessary, so urn:dev:cgi is OK.

And yes, eventually it would be good for you to post about this I-D to
the urn-nid mailing list:

https://www.ietf.org/mailman/listinfo/urn-nid

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Jari Arkko <[email-masked]>
Date: Thu, 23 Feb 2012 23:26:12 +0200

Peter,

> I think you were missing the point of my message:

Ah, sorry :-)

> that administered
> uniqueness is not necessary

that I agree with

>   so urn:dev:cgi is OK.

Will do.

Jari