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: > > 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-----
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
