On Oct 25, 2009, at 10:32 PM, Song Haibin wrote:
Hi, I have not finished the review, but I have several questions on this document.1). I am not sure how the TRUN usage defined in this document will work well. Who will be responsible for calculating the turnDensity and how? How to update the TURN server information in the overlay when some TURN serversleave the overlay suddenly, to aovid getting the "old" information?2). In section 4.1.1 "Storage Permissions" said "RELOAD addresses this issueby only allowing any given node to store data ata small number of locations in the overlay, with those locations being determined by the node's certificate." This rule will limit the applicationsthat the protocol could support. E.g, for streaming or file-sharingapplications, it is very practical to put the resource providers' address information under the same Resource ID which is the hash of the contentname, despite the node ID or username information contained in the certificate of the resource provider.
This is how the BitTorrent DHT works and it's sloppy and insecure. To solve this problem you could create an extension such as Multicast groups in Overlay networks.
I've implemented the following algorithm, it works and is fairly heavily tested.
http://dks.sics.se/pub/mcastposter.pdf Julian
3). How do you prevent "via list" being modified by the intermediate peers? This is very important because it is related to whether you can get a rightreturen path for your response.4). In section 5.4.2.4.2., RouteQuery response should at least include a next hop peer infomation if you want to use this message for the iterativerouting.5). I'm not sure about the necessity of access control policies in section 6.3. I think it will make sense only when these access control policies are generic to all usages that will be built on top of RELOAD. Other than that, I would suggest to remove this section and define these policies in eachusage document. Comment 2 is also related to this topic. Thanks! Haibin-----Original Message----- From: p2psip-bounces at ietf.org [mailto:p2psip-bounces at ietf.org] On Behalf Of Brian Rosen Sent: Saturday, October 24, 2009 2:55 AM To: Cullen Jennings; P2PSIP WG Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base <as chair> If you think the draft is missing something big, or has some other serious shortcoming that makes it inappropriate to hold a WGLC, please speak up now. We'll give everyone a few days to look over this version, and then decide if we will start it. If you had signed up to review NOW would be the time to do it, on this version. That was NOW, and not "soon", please. Brian On 10/23/09 2:38 PM, "Cullen Jennings" <fluffy at cisco.com> wrote:We just submitted a new version of the base draft at http://www.ietf.org/id/draft-ietf-p2psip-base-05.txt (there is a new version of the sip-usage as well). The major changes are mostly a very long and excruciating editorial pass to try and improve the grammar. At this point, I don't know of any significant issues thatneed to beresolved. I think the draft is ready for WGLC. I'm sure that during WGLC some major issues will come up, some important decisions will be made about what needs to bemandatory andsuch, and we will find several small inconsistencies andtypos in thedraft as well as things that need a clearer explanation. This will take some time and I expect multiple more revisions for this draft before it is published, however, I do think this is theright time tostart WGLC. Lets get the issues on the table and then we can start resolving them. Thanks, Cullen <in my individual contributor role> _______________________________________________ P2PSIP mailing list P2PSIP at ietf.org https://www.ietf.org/mailman/listinfo/p2psip_______________________________________________ P2PSIP mailing list P2PSIP at ietf.org https://www.ietf.org/mailman/listinfo/p2psip_______________________________________________ P2PSIP mailing list P2PSIP at ietf.org https://www.ietf.org/mailman/listinfo/p2psip