-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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: > 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 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. > > http://tools.ietf.org/id/draft-jimenez-p2psip-coap-reload-00.txt - -- Marc Petit-Huguenin Personal email: [email protected] Professional email: [email protected] Blog: http://blog.marc.petit-huguenin.org -----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----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
