Re: [icnrg] [T2TRG] ICNRG/T2TRG subject of the day: device naming, data naming, semantic interoperability

[Ravi Ravindran <[e-mail]>]

Contributing to this thread:

On the naming aspect, in the section 5.1 of the ICN-IoT requirements draft https://tools.ietf.org/html/draft-zhang-icnrg-icniot-requirements-01
 we don't restrict naming only to content, but also to services and devices.

The naming itself has to satisfy heterogeneous application requirements, hence needn't be contextual as the example below, but can be self-certified flat names too, e.g. hash of content object or of a public key. The type of name determines the binding between name and the key. For contextual names, it requires a certificate, while a self-certified flat names can be locally validated without involving a third party.

On the discovery aspect, ICN-IoT discovery discussions in the context of an ICN-IoT middleware design has been presented in https://tools.ietf.org/html/draft-zhang-icnrg-iot-architecture-00
(the presentation slides are here https://www.ietf.org/proceedings/interim-2016-icnrg-03/slides/slides-interim-2016-icnrg-03-9.pdf
).  The main difference from the IP architecture is that discovery processes are name-based hence allows efficient realization of Self-configuration features at the device and service level.

Regards,
Ravi

-----Original Message-----
From: T2TRG [mailto:[e-mail]] On Behalf Of Carsten Bormann
Sent: Wednesday, November 09, 2016 7:50 AM
To: [e-mail]; [e-mail]
Subject: [T2TRG] ICNRG/T2TRG subject of the day: device naming, data naming, semantic interoperability

# Subject of the day: device naming, data naming, semantic interoperability

A few days are left until we have the joint T2TRG/ICNRG meeting on Sunday.  Until then, maybe it is a good idea to prepare for the discussion on the two mailing lists.  (Apologies for the cross-posting if your mail reader isn't collapsing.)

The subject I'd like to propose for today (US time zone) is:

## device naming, data naming, semantic interoperability

### REST

In the REST world, which is inspiring T2TRG, naming is mostly done through the URI.  The authority part (e.g., a host name or an IP
address) could stand for a device.  (The authority is also part of the origin, which is relevant for its security properties.)  The URI path that follows the authority then names the data on the device.

RFC 7320, URI Design and Ownership, tells us that it is up to the server, i.e. the device, to make up the names, and clients should not be expecting any structure there.  But then, not all interfaces on the web are exactly like this, and RFC 6570 URI templates as well as URI query parameters (possibly submitted as instructed by a form) point to some client-controlled naming.

In a REST world, we expect a lot of discovery to happen before a name is formed:
-- device discovery (server discovery)
-- resource discovery (e.g., via /.well-knwon/core and a resource directory)
-- discovery of related semantic information (e.g., forms)

We also expect using media types in order to convey semantic information about a resource representation.

In the COMI work, we also have names ("selectors", based on a YANG model of the data) as payload of FETCH and PATCH operations; these can reach into a datastore in a finely-grained way.

I'm not going to start discussing semantic interoperability here; the mail is already too long, but we'll have to do that at some point.

### ICN

In the ICN world, data is named, not devices.  For a thing (where thinginess is defined as a relationship to the physical world), it is sometime hard to distinguish between the device name (sensor for temperature in Room 5180) and the name of the data (temperature in Room 5180).  A random example I stumbled over recently:

/city name/bangalore/street name/cunningham road/location/20/corner/east /sensor type/video/sensorID/1

This doesn't have an address in the networking sense in it, but it does have a device ID...

There is an assumption that a name can be used to derive security properties, e.g. to validate signed data under this name.

There is some assumption that a client can at least form progressions of names in order to obtain chunks of an object and newer versions of an object.  ICN "discovery" often is about finding the data when you already have the name -- I don't know much about ICN name discovery schemes; maybe somebody else can chime in.

### Discussion

So what can we learn from how the naming issues are treated in the two worlds?  How would an "IoT ICN" name its data?  What ICN ideas can we (should we) integrate into CoRE, and v.v.?  Can we learn something from the way security is being handled?  How does a client learn about these names (discovery, standards, "thing descriptions", ...)?

Any form of input is welcome, from a two-liner mail here up to a position paper and the announcement of a talk in Seoul...

Grüße, Carsten

_______________________________________________
T2TRG mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/t2trg