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

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 3 Feb 2015 14:11:23 +0200

Hi,

thanks Matthias for all your input.

At this point, revision 07 of the draft (with a Security Considerations
Section, which was missing in 06) addresses all the comments received.
We are going to ask the document shepherd (Carlos in the cc:, who
cochairs the P2PSIP WG) to initiate the publication request process.

Thanks,

Gonzalo

On 29/01/2015 4:40 PM, Jaime Jiménez wrote:
> 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]
> <mailto:[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
>> <http://link.springer.com/article/10.1186/1687-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]
>> <mailto:[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
>>
>