Subject: [core] Fwd: New Version Notification for draft-shelby-core-resource-directory-00.txt

From: Zach Shelby <[email-masked]>
Date: Mon, 27 Jun 2011 15:20:06 +0300

We have submitted an initial resource directory interface specification draft, and would like to spend 10 minutes in Quebec to present it.

http://tools.ietf.org/html/draft-shelby-core-resource-directory-00

Zach

Begin forwarded message:

> From: [email-masked]
> Date: June 27, 2011 3:15:06 PM GMT+03:00
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: New Version Notification for draft-shelby-core-resource-directory-00.txt
> 
> A new version of I-D, draft-shelby-core-resource-directory-00.txt has been successfully submitted by Zach Shelby and posted to the IETF repository.
> 
> Filename:	 draft-shelby-core-resource-directory
> Revision:	 00
> Title:		 CoRE Resource Directory
> Creation date:	 2011-06-27
> WG ID:		 Individual Submission
> Number of pages: 16
> 
> Abstract:
>   In many M2M scenarios, direct discovery of resources is not practical
>   due to sleeping nodes, disperse networks, or networks where multicast
>   traffic is inefficient.  These problems can be solved by employing an
>   entity called a Resource Directory (RD), which hosts descriptions of
>   resources held on other servers, allowing lookups to be performed for
>   those resources.  This document specifies the web interfaces that a
>   Resource Directory supports in order for web servers to discover the
>   RD and to registrer, maintain, lookup and remove resources
>   descriptions.  Furthermore, new link attributes useful in conjunction
>   with an RD are defined.
> 
> 
> 
> 
> The IETF Secretariat

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 28 Jun 2011 17:13:09 +0300

Hi Zac,

I have had a look at the draft, it looks an interesting one

I have a first question, maybe it is because I have read it quickly, but 
I found strange that
the Registration interface does not contain an attribute to register 
also the IP address of the sensor

without it is not clear how you would target the request to the resource 
once you have discovered them
through the Lookup interface.

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 28 Jun 2011 20:40:28 +0300

> through the Lookup interface.
actually we can also avoid to have an IP address attribute in the interface,
if we automatically store/update in the resource created/update in the RD
the source IP address of the POST/PUT request

of course we have to provide it back at lookup time.

thoughts?

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

---

From: Zach Shelby <[email-masked]>
Date: Wed, 29 Jun 2011 10:41:56 +0300

Hi Sal,

> the source IP address of the POST/PUT request

That is exactly what is assumed by the draft. Definitely needs to be made clear as we have just been assuming it was obvious. 

> of course we have to provide it back at lookup time.

Yes, this is done by including the full scheme + authority in the URI part of the link format when answering a lookup. For example:

GET coap://resource-directory/rd?rt=TemperatureC

2.05 Content
<coap://node1/sensor/temp>;rt="TemperatureC"
<coap://node2/sensor/temp>;rt="TemperatureC"

Where node1/node2 is replaced by the IPv6 address and possibly the port of the nodes collected when they registered. 

Zach

> 
> thoughts?
> 
> cheers
> /Sal
> 
> -- 
> Salvatore Loreto
> www.sloreto.com
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Wed, 29 Jun 2011 09:50:18 +0200

> That is exactly what is assumed by the draft. Definitely needs to be made clear as we have just been assuming it was obvious.

Probably also having a way to specify the source of the message will
be useful in some scenario.

Assume that a NAT or a proxy is involved in the process, in that case
the source IP address available at the RD is not pointing to the
actual source CoAP server anymore.

Don't know if this can be done here using some existing coap or
link-format options, or if we need a specific option to signal it.

Best,
Angelo

---

From: Szymon <[email-masked]>
Date: Wed, 29 Jun 2011 10:57:14 +0300

Can be done, for example:

<coap://[2001::1234]/sensor/temp>;rt="TemperatureC"

In addition proxy/gateway maybe could alter links and insert missing source ip?

Szymon
Sensinode Ltd

> On Wed, Jun 29, 2011 at 09:41, Zach Shelby<[email-masked]>  wrote:

---

From: Zach Shelby <[email-masked]>
Date: Wed, 29 Jun 2011 11:00:20 +0300

> link-format options, or if we need a specific option to signal it.

I agree, this would be useful in cases where an entity is registering on behalf of an end-point. We have also been thinking about the need for this. The way this should be done is to add a query string parameter to register the authority to the POST registration request. I also include the scheme in case that differs from the protocol being used to register with. For example:

POST coap://resource-directory/rd?authority=coap://node1:61616 

Zach

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 29 Jun 2011 11:01:57 +0300

>> That is exactly what is assumed by the draft. Definitely needs to be made clear as we have just been assuming it was obvious.
Hi Zach,

if I read the End-point Name (n) parameter definition, it is not clear 
it is for carrying the IP address
especially an IPv6+Port...
among the other because of the 63 octets limitation

> be useful in some scenario.
that is really a good point to consider,

> actual source CoAP server anymore.

the IP address you insert can not be the same of the source of the message
e.g. if you have a NAT in between
so consider both it is important
also because the RD is a good candidate to keep open an eventual hole 
within a NAT

> link-format options, or if we need a specific option to signal it.
if we design the RD correctly we do not need extra options in CoAP 
neither in the link-format

-- 
Salvatore Loreto
www.sloreto.com

---

From: [email-masked]
Date: Wed, 29 Jun 2011 13:02:38 +0200

Hi Zach,

Your new draft and the current discussions are very interesting.

I also have few questions about the draft

1) Registration procedure
Why indexing the endpoints with the name and not the node id?
All end points have some kind of unique identifier (EUI64,...) but not all 
nodes have a configured name.
Also when the node changes its name we may have duplicate entries in the 
directory if regitration/removal is not handled properly.

2) Update procedure
It seems an end point doesn't need to include again and again the 
link-format resource list when it refreshes its directory entry.
But the exact behavior is not clear.
What the rd is supposed to do when the payload is empty and the etag in 
the PUT request doesn't match the etag in the directory?
In my opinion a noticable error code should inform the end point that it 
needs to perform a full refresh with a payload.

3) Lookup
a)There is no way to enumerate the end points in the directory.
We could make a difference between  the resources /{rd-base} and 
/{rd-base}?
/{rd-base}? would be the lookup interface and /{rd-base} a resource 
containing the list of  /{rd-base}/ {endpoint name}  links.
Example
GET /rd
</rd/node1>,
</rd/node2>,
GET /rd?
<coap://node1/temp>;rt="Temperature",
<coap://node2/temp>;rt="Temperature"

b)The result of a lookup becomes rapidly quite large because of the full 
target URI.

c) Is there a risk of cache/etag mishandling because of the translated 
target URI? The problem is that the payload of a GET /rd/node1 is not the 
same as the payload of the corresponding PUT request.
PUT /rd/node1
</temp>;rt="Temperature"
GET /rd/node1
<coap://node1/temp>;rt="Temperature"

Matthieu