Subject: [P2PSIP] draft-jimenez-p2psip-coap-reload

From: Jaime Jiménez J <[email-masked]>
Date: Fri, 24 Feb 2012 12:01:49 +0100

Hello,

we just submitted a draft to the p2psip WG that proposes a CoAP Usage for RELOAD.

Constrained Application Protocol (CoAP) is a specialized web transfer protocol.  It realizes the Representational State Transfer (REST) architecture for the most constrained nodes, such as sensors and actuators. 

The CoAP Usage provides the functionality to federate Wireless Sensor Networks (WSN) in a peer-to-peer fashion.  It also provides a rendezvous service for CoAP Nodes and caching of sensor information. 

http://tools.ietf.org/id/draft-jimenez-p2psip-coap-reload-00.txt 

Best Regards,
-- Jaime

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 24 Feb 2012 06:50:11 -0800

Some comments:

1. Section 4:  ".. is calculated as a SHA-1 hash..."

This is defined only for CHORD-RELOAD, other algorithms may use a different
way of computing the Resource-ID (unless only CHORD-RELOAD can be used with
this usage, in which case it should be explicitly stated).

Also, URIs are case insensitive, so they need to be canonicalized before been
converted to a Resource-ID.

2. Figure 2:

Messages 4 and 5 should be AppAttach.

200 OK has no meaning in RELOAD (messages 6 and 7).

3. Section 7, last paragraph: "The only difference is data_value..."

data_value is never used.

4. Section 7, CoAPCaching definition

The values to select coap_caching_type are never defined (coap_caching_type
should be an enum).

5. Section 7.1 Definition of ProxyCache, SensorEntry

[] should be redefined to carry the length (<0..length>)

6. Section 7.1 Definition of SensorEntry

[] should be redefined to carry the length (<0..length>)

"opaque coap_uri;" should define a length (e.g. opaque coap_uri<0..2^16-1>)

7. Section 7.2 Definition of SensorCache

[] should be redefined to carry the length (<0..length>)

8. Section 7.2 "last_awake" definition

Perhaps it's simpler to use the same format than RELOAD to store time, i.e.
milliseconds since the epoch.

9. Section 7.2 Definition of SensorValue

"value" should be redefined as having a length.

10. Section 7.2 "measurement_time" definition

Unit is not defined.

11. Section 7.2 "lifetime" definition

Unit is not defined.

12. Section 8.1 "...which contains a Node-ID..."

CoAPRegistration does not contain a Node-ID.

13. Section 8.1 URI-NODE-MATCH

This is a new access control policy, so it needs to be defined.

14. Section 8.1 Definition of CoAPRegistration

Because of the fact that some RELOAD client may not be directly routable
(second bullet of RELOAD section 3.2.1), I would add a "Destination
destination_list<0..2^16-1>;" field.

15. Section 8.1 Definition of CoAPRegistration

The () notation for coap_uris is not defined, but the two lines can be
replaced by this:

opaque coap_uris<0..2^16-1>;

There is no explanation on the internal format of coap_uris, for example that
the uris must be separated (or terminated?) with ";".

16. Section 8.2 "which contains a Node-ID..."

CoAPCaching does not contain a Node-ID (ProxyCache does).

17. Section 8.2 URI-MATCH

This is a new access control policy, so it needs to be defined.

Nits
- ----

- - Section 4:

s/registering register/registering/
s/RESOURCE-ID/Resource-ID/

- - Section 5:

s/RESOURCE-ID/Resource-ID/

- - Section 7.2:

s/NodeID/Node-ID/

On 02/24/2012 03:01 AM, Jaime Jiménez J wrote:
> Constrained Application Protocol (CoAP) is a specialized web transfer
> protocol. It realizes the Representational State Transfer (REST)
> architecture for the most constrained nodes, such as sensorsand actuators.
> 
> 
> The CoAP Usageprovides the functionality to federate Wireless Sensor
> Networks (WSN)in a peer-to-peer fashion.  It also provides a rendezvous
> service for CoAP Nodes and caching of sensor information.
> 

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Jaime Jiménez J <[email-masked]>
Date: Wed, 29 Feb 2012 08:52:05 +0100

Hi,

Thanks for the comments we'll update the draft as specified.
 
BR,
-- Jaime

On Feb 24, 2012, at 4:50 PM, Marc Petit-Huguenin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Some comments:
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iQIcBAEBCAAGBQJPR6OiAAoJECnERZXWan7E/g4P/16gfK4nFltd97CIvnR8zipo
> 4LzC8GdzBSokZRv0el3UPzrUUCyBi03jWKvhegwstMAKJfk+S2h7hGp0BP+mC4Db
> EESrZ9BBfv/6qbW0RJUYrkFzMBUN6EuYc4p+5zs0JpKIqisev/dEI6D6e5oYIKOy
> Hy4v7NRXdK6lwnPgIknNsdbaM91+MMFHoCcXrcvlVdoHDGDPyae3q4JjZtwpOHaG
> FDESCxI/Za9v0eCCgBVG6MFMn7fL5gIc7WlQD7i72f9IIMfs55i3ttA/dMz/Lxcv
> RdctpPCOXk6zrMk+rAQnrePgubUNjU4qd9gm7Ef8BuB4Z8yt8yKrNV4WEerBZ3Fr
> PN6XCdMkwfYcj/74mVV0jlfC/xUJyTlZ8pQbspz7YcVgr/OCJjwts8RPULWCvT6X
> qR6rGdwSd+CaTkLfXxqg6WjT5x5pIGkpemJP5cpNJh3InqsgNQ1rVSa7qrkNCYUG
> aW6IoMKH+jSaTHlyC20TleCWRJpdPkliKu1q5PT8vbDXWzl3riU6D8oQGUXUB1ca
> PTE4FWXvjdWTfrhmgmZL6a1+rVKqgB2eWdh+o8HRweWxTDnvVmqIf+R1bseKRpHh
> ItHeWENs0psGVggc0/u/hHfKvNW7Usf0Z92NnqWNnYvvbSzH6z1+Z2mYAfwtvCyF
> en8J08gcGH17NJ8tdUyw
> =egUL
> -----END PGP SIGNATURE-----