Re: [apps-discuss] Device URNs

[Jari Arkko <[e-mail]>]

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