-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 More questions, comments and nits:
- - A.9. In section 5.1.2, 5th paragraph: "As an example of the second strategy, if node D receives a message from node C with transaction X and via list (A, B), it could store (X, C) in its state database and forward the message with the via list unchanged. When D receives the response, it consults its state database for transaction id X, determines that the request came from C, and forwards the response to C." If I understand correctly this whole paragraph, when a message is forwarded it keeps the same transaction_id, because if the response received by D was using a different transaction_id, say Y, it could not retrieve (X, C) from the state database. Is this analysis correct? - - A.10. It seems that this version of RELOAD lacks the support of virtual servers (see draft-harjula-p2psip-loadbalancing-survey), more precisely a way to share connections between two virtual servers on the same physical server (see Frank Dabek, M. Frans Kaashoek, David Karger, Robert Morris, Ion Stoica, Wide-area cooperative storage with CFS: "Use of virtual servers could potentially increase the number of hops in a Chord lookup. CFS avoids this expense by allowing virtual servers on the same physical server to examine each others' tables: the fact that these virtual servers can take short-cuts through each others' routing table exactly compensates for the increases number of servers."). Because the certificates contains a list of Node-IDs, it is not possible to know on a hop by hop basis what are the source and destination NodeIds of a specific message. Section 3 of draft-rosenberg-dispatch-vipr-reload-usage seems to acknowledge that by adding a PeerID Shim to exchange the source and destination peerIDs (aka Node-IDs). Because of this, it is probably a good idea to add in p2psip-base the possibility to know the source Node-ID and destination Node-ID of a message. One way to do that would have be to have the sender of a message add its own Node-ID in the via_list, and the Node-ID of the destination in the destination_list before sending a message (similar to what SIP is doing), but I guess that it is too late for such a modification. - - A.11. Looking at the examples in section 3.3, it seems that the via_list is updated only when the message forwarded is a request but not for responses, but I cannot find this anywhere in the text. So are all messages processed the same way when forwarded (and via updated on all types of messages) or specifically on requests? (by testing the last bit of message_code). - - A.12. Section 10.3 states that "[t]he SubjectAltName field in the certificate contains the following values: One or more Node-IDs...", but nowhere it is said how to request multiple Node-IDs. Is it an URL parameter of the POST request? An attribute in the Certification Request object? Nits ==== - - Section 5.3, in the list "Security Block:" s/""Message Contents"/"Message Contents"/ - - Section 5.3.2.1 s/destination_value/destination_data/ - - Section 5.3.4 "overlay + transaction_id + MessageContents + SignerIdentity" The "+" should probably be replaced with "||". - -- 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.10 (GNU/Linux) iEYEARECAAYFAkzqxUgACgkQ9RoMZyVa61fLpQCglb3AQGXUnEmD6athMaIGFBAx vLkAn2r+Gy54Z/sJHMNv/j0i4Ic4y2ZZ =bP6t -----END PGP SIGNATURE----- _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
