Subject: Re: [dispatch] Review of draft-jimenez-p2psip-coap-reload

From: Jaime Jiménez <[email-masked]>
Date: Thu, 29 Jan 2015 14:40:51 +0000

Hi,

I just submitted the latest version of the draft:
http://datatracker.ietf.org/doc/draft-jimenez-p2psip-coap-reload/

From previous discussions I have gathered all the actionable items on the draft.

Reviewer: 	Thanks for your comments, they really helped to get the whole idea. I think it would improve the draft when the introduction clearly explains the layering (by also providing use cases) and lists the features that CoAP will use from RELOAD (e.g., caching and that DNS becomes obsolete and that the addresses are resolved in a completely different way).
[TODO:1] DONE

Reviewer: 	The caching and discovery mechanisms do not appear to be compatible with the normal CoAP mechanisms. I think from a programmers point of view, this abstraction should be transparent, that is, the programmer can use the same CoAP APIs and make the same requests to achieve application goals as if there was no RELOAD network underneath. Maybe this is the case, but it is hard to see with all the new IANA considerations :)
[TODO:2] DONE:  Normal CoAP caching is done at the proxies (section 7), RELOAD caching requires some form of structure of the data to be stored in the overlay. I have removed the Resource type part of the IANA considerations, when we first did the draft, CoAP’s RD did not define the proper way to name resource types. Now it does and we can use the same resource types. The rest of the IANA considerations are for the RELOAD part of the Usage, not the CoAP one.

Reviewer: 	The main technical issue is then the use of URIs. Since they mean something completely different in this draft, they need their own scheme. A look at the alternative transports in CoRE might help here, but it was also their main issue and I currently do not know if it is resolved yet.
[TODO:3] Right, this issue is still being discussed. That is why we chose to use URIs in a way whose definition was stable.

Reviewer: 	A secondary issue is the integration with resource directories. I think, it would be good if normal RDs and RELOAD-RDs could coexist and link to each other. This would mean they use the same mechanisms
BTW: Normal RDs are not distributed in the P2P sense, but they can be mirrored and distributed like DNS servers.
[TODO:4] Yes, that is an interesting idea, which would result in a different approach to the whole issue than the one taken by the draft. It may be worth exploring this space in the future, but we prefer to stick to the traditional RELOAD usage in this draft.

Reviewer: 	 It might be useful to align the terminology for constrained nodes with the LWIG terminology RFC 7228 (cf. LR-WPAN).
+ I will align the terms when applicable.
Reviewer: 	The description for PN missing (used in figure and probably a CoAP proxy node).
+ You are right, I should write that part too.
[TODO:5] DONE

Reviewer: 	The RELOAD term "rendezvous" is misleading, since the described action is a simple lookup and not the establishment of a connection.
+ I will change the title to Lookup instead of Rendezvous.
[TODO:6] DONE

Reviewer: 	 CoAP "Nodes" to lower case
+ I will change that
4. Registering CoAP URIs
Reviewer: 	"registering register" in first paragraph
+ I will change that
6. Forming a direct connection and reading data
Reviewer: 	Title capitalization is missing for this section heading
+ I will change that
[TODO:7] DONE

Thanks!
- - Jaime Jimenez

On 10 Nov 2014, at 10:09, ejajimn <[email-masked]> wrote:

> Hi Matthias,
> 
> Thank you for the comments, I still haven’t modified the draft but I will take them into account and forward you the modified version as soon as it is done. 
> 
> Now regarding the link to the paper you forwarded. I have briefly scanned through it and what they proposed is similar to our draft and even more similar to our paper in 2012 (http://link.springer.com/article/10.1186%2F1687-1499-2012-121) and the DRD draft (http://tools.ietf.org/html/draft-jimenez-distributed-resource-directory-00.html). Of course now in late 2014 their approach introduces a lot of new things from CoRE that we did not have back then. Seeing that other people come up with this problem and similar solution is encouraging to try to work on it some more.
> 
> The basic principle of having a distributed network of WSN islands is the same as in our work. They also rely on a gateway that acts as CoAP server/client/http proxy/…and as a local RD on behalf of other CoAP EPs in the WSN. They use the .well-known to link the EP resources to the .well-known on the GW, which makes sense.  The different part is that they use two different DHT systems: DGT and DLS, the GW has to be a peer on both of them. DGT ads the GPS coordinates to the mapping, making discovery bind to the location of the device, this means that in mobility scenarios it would not work alone. That is why they also use DLS in parallel, to also have name resolution. 
> 
> In our draft we are only looking at the second case, and we already do it very similarly as they do using DLS. Another issue is that we are trying to marry RELOAD and CoAP, not only DHTs and CoAP. RELOAD has its own quirks so I would suggest to keep the two differentiated even if they are similar. However it would be great to have people collaborate on DRD too.
> 
> Ciao,
> - - Jaime Jimenez
> 
> On 03 Nov 2014, at 18:51, Kovatsch Matthias <[email-masked]> wrote:
> 
>> Dear Gonzalo and Jaime,
>> dear list
>> 
>> Thanks for your comments, they really helped to get the whole idea. I think it would improve the draft when the introduction clearly explains the layering (by also providing use cases) and lists the features that CoAP will use from RELOAD (e.g., caching and that DNS becomes obsolete and that the addresses are resolved in a completely different way).
>> 
>> I think I will need this update to better understand some of the described features. The caching and discovery mechanisms do not appear to be compatible with the normal CoAP mechanisms. I think from a programmers point of view, this abstraction should be transparent, that is, the programmer can use the same CoAP APIs and make the same requests to achieve application goals as if there was no RELOAD network underneath. Maybe this is the case, but it is hard to see with all the new IANA considerations :)
>> 
>> The main technical issue is then the use of URIs. Since they mean something completely different in this draft, they need their own scheme. A look at the alternative transports in CoRE might help here, but it was also their main issue and I currently do not know if it is resolved yet.
>> 
>> A secondary issue is the integration with resource directories. I think, it would be good if normal RDs and RELOAD-RDs could coexist and link to each other. This would mean they use the same mechanisms
>> BTW: Normal RDs are not distributed in the P2P sense, but they can be mirrored and distributed like DNS servers.
>> 
>> I also stumbled upon this paper, which proposes a similar approach:
>> http://ieeexplore.ieee.org/xpl/abstractAuthors.jsp?tp=&arnumber=6899579
>> Are you aware of this work? Maybe there is something useful that can be included in the draft.
>> 
>> Best regards
>> Matthias
>