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

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 2 Oct 2014 15:41:50 +0300

Folks,

per the agreed plan to progress this draft, we have gotten two dedicated
reviewers to look at the draft.

http://datatracker.ietf.org/doc/draft-jimenez-p2psip-coap-reload/

Cullen reviewed it from a RELOAD perspective and sent his review to this
list some time ago. Matthias (in the cc:) has now reviewed the draft
from a CoAP point of view. Please, find below his review and Jaime's
initial responses (preceded by a '+' sign) to his comments.

Cheers,

Gonzalo

-------- Original Message --------
Subject: RE: Reviewing a CoAP/P2PSIP draft
Date: Tue, 12 Aug 2014 14:50:54 +0000
From: Kovatsch  Matthias <[email-masked]>
To: Ari Keränen <[email-masked]>

Hi Ari

Is there an official process to submit the review? If not, here it is simply
by mail:

Overall, I am missing the motivation for having a RELOAD abstraction on top
of CoAP. There is no new functionality provided through this combination and
it only weakens both concepts (REST and P2P overlays).

+ The abstraction layer is CoAP on top of RELOAD. Some of the advantages
provided by RELOAD is that we can actually have discovery in a P2P way,
without a server acting as RD. Another is that P2P intrinsically provides
caching, resilience, etc. I will add text along those lines to the
introduction of the draft.

If a sensor/actuator Usage for RELOAD is required, I think it is better
realized in a direct fashion without CoAP.
+ The main functionality we use from RELOAD is discovery. The rest of the
sensor/actuator functionality is implemented via CoAP.

Mixing actual CoAP URIs and URIs that serve as simple ID is very confusing.
+ Yeah you are right in the sense that a two-step discovery process is a bit
more inefficient, but necessary when using DHTs and compensated by the
possibility of having a distributed lookup using RELOAD.

The contents of the RELOAD Sensor Type Registry (temperature, humidity,
etc.) also imply that this draft defines an additional application layer
that is not compatible with CoAP/REST.
+ The RELOAD sensor type registry is purely orientative, it is better that
we use the IANA references specified in the CoAP RFC6690.

I might be missing the use case for this draft, which might be helpful in
the draft itself.
+ You are right, an example could be from this EURASIP paper in which we
give some use cases, I will include one of them in the draft too (I will
update it to the latest versions of RELOAD and CoAP). The paper can be found
at: http://users.piuha.net/jaime/coap_reload_long.pdf

My more specific comments are:

1. Introduction
- The meaning of the relative URI paths in the 6th paragraph is unclear
(later examples show how they are used with a draft-specific rule that is
not explicitly described)
+ In the example, the full path for a sensor behind the proxy would be
coap://overlay-1.com/proxy-1/temperature-1 .The Proxy device has to know the
Overlay address (since it is connected to it) and has to know its own
Node_ID, therefore he can create the whole path to itself and just append
the two new devices. I think this should be clear enough for RELAOD
implementors. If you have a suggestion to clarify the sentence, please let
me know.
- The use of URIs is fuzzy. A base URI (basically the DNS name) would relate
to a node, but a node usually has several URIs for each of its resources
+ If a Proxy with three sensor devices would have the three following URIs
(one per sensor)
coap://overlay-1.com/proxy-1/temperature-1
coap://overlay-1.com/proxy-1/temperature-2
coap://overlay-1.com/proxy-1/temperature-3

- Registration and lookups are already provided by CoRE resource directories
and Web Linking
+ RD is so far not distributed AFAIK, and RELOAD could provide an extra way
to do discovery in a distributed way.
- Rendezvous: Having URIs no P2P routing is required to exchange CoAP
messages. Relying on CoAP proxies already solves the NAT/firewall problem
for WSNs without RELOAD functionality.
+ In our use case we use the Overlay to look the domains up, not DNS. Of
course a network of sensors could be implemented in the traditional way.
This draft explains how to do it in an alternative way, a distributed way
using overlays.
- Caching is already a fundamental part of REST.
+ This would be overlay caching, providing extra resilience.

3. Architecture
- 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.
- The description for PN missing (used in figure and probably a CoAP proxy
node).
+ You are right, I should write that part too.

4. Registering CoAP URIs
- From where do peers get the initial URI used in the hash? These URIs do
not even address a working CoAP resource.
+ If the proxy is part of the RELOAD overlay it has to know both its own
Node_Id and the overlay he is connecting to. The URI is
coap://OVERLAYID/NODEID/
- The use of the .well-known location in
"coap://overlay-1.com/proxy-1/.well-known/" is incorrect. Using the entry
URI that is the base of the relative URIs would even make more sense.
+ Since we are not using the RD to register resources, but we use the
Overlay instead, we have tried to adapt it to RELOAD's registration process.
- The formal handling of the relative paths is still not defined.
+ Perhaps you could elaborate a bit more this comment cause I don't fully
understand it.

5. Rendezvous
- 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.

6. Forming a direct connection and reading data
- Should reading data be a normal, direct CoAP GET request?
+ The reading of data is, in a ways, a normal CoAP Get Request. However it
is routed via RELOAD instead of using DNS.
- All resulting URIs point to one central reverse-proxy, which completely
removes the distributed P2P idea.
+ Perhaps you could elaborate a bit more this comment cause I don't fully
understand it.

7. Caching Mechanisms
- How are the CNs supposed to send their data to the proxy?
+ Each CN sits under a PN and sends the data through it. The PN can do
caching in the Overlay like any other RELAOD node would.
- What is the purpose of the additional caching mechanism? It furthermore
breaks the underlying REST architecture, as the used structures are unaware
of media types.
+ The additional caching mechanism adds resiliency to the network, since it
is done in a distributed fashion.

Editorial comments:

Abstract
- CoAP "Nodes" to lower case
+ I will change that

4. Registering CoAP URIs
- "registering register" in first paragraph
+ I will change that

6. Forming a direct connection and reading data
- Title capitalization is missing for this section heading
+ I will change that