>-----Original Message----- >From: Cullen Jennings [mailto:[email protected]] >Sent: Monday, October 26, 2009 11:46 PM >To: Song Haibin >Cc: P2PSIP WG >Subject: Re: [P2PSIP] New version of draft-ietf-p2psip-base > > >On Oct 26, 2009, at 3:32 , 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? > >The idea was to specify the minimal simple thing and allow for >much more advanced things to be developed in the future. Right >now, the operator of the DHT would specify the turnDensity - >they could presumable measure by probing the overlay. Keep in >mind the two interesting values for overlays are no one is a >TURN server and everyone is a TURN server. >
In that case, the turnDensity is really dynamic, especially in an overlay with high churn rate and there are few TURN servers in the overlay. A TURN server has to register its information to the overlay with different times when the turnDensity changes. Does it need to delete some copies of its information or register more copies when the turnDensity changes? I don't think this discovery mechanism in the document is mature to implement. Haibin >> How >> to update the TURN server information in the overlay when some TURN >> servers leave the overlay suddenly, to avoid getting the "old" >> information? > >The data times out and goes away and and this is part of the >reason for finding a bunch. > >> >> 2). In section 4.1.1 "Storage Permissions" said "RELOAD addresses >> this issue >> by only allowing any given node to store data at >> a small number of locations in the overlay, with those locations >> being >> determined by the node's certificate." This rule will limit the >> applications >> that the protocol could support. E.g, for streaming or file-sharing >> applications, it is very practical to put the resource providers' >> address >> information under the same Resource ID which is the hash of the >> content >> name, despite the node ID or username information contained in the >> certificate of the resource provider. > >Sure, but without this rules peers are would have to store an >unlimited amount of data on behalf of others. A key premise of this >work since before the WG was charter was that the protocol should be >possible to use in a way where one could deploy a overlay for some >application usage and not have it become used for file sharing. Note >that if the overlay wants to allow kinds that have no authorization >rules and allow anyone to write anywhere, there is nothing the spec >that forbids that. It's up to the usage. So if someone wants >to make a >file-sharing usage, well storing the whole file in the DHT is >probably >not the best design but one could certainly make a usage that did >exactly that. > >> >> 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 right >> returen path for your response. > >Well we can't really secure this in any practical way, or more >importantly, we can prevent the intermediate peers from misrouting >the request. The misroute of the response is no more serious than the >misroute of the request. It's a pretty fundamental limitation of an >overlay system like this. However, the overlay security of the system >does not depend on stopping this. This can be used to DOS the systems >but not much else. Keep in mind, the same is true of IP that is >running over. > >> >> 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 >> iterative >> routing. > >Agree this is needed but it is somewhat DHT specific. I forget the >details but I think it was Salman who pointed out that for some >unstructured overlays, you would need something other than the next >hop. Because of that, we made the answer DHT specific. For the Chord >DHT specified here, 100% agree with you we need the next hop and the >message to return that is defined in Section 9.8 > >> >> 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 >> each >> usage document. Comment 2 is also related to this topic. > >Clearly many usage documents can share many of the basic >policies so I >think it make more sense to define at least the ones needed for the >charter of this WG in the base draft. > >> >> Thanks! >> Haibin > >Thanks for reviewing it - much appreciated. > >Cullen <in my individual contributor role> > >> >> >> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] >>> 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" <[email protected]> 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 that >>> need to be >>>> resolved. 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 be >>> mandatory and >>>> such, and we will find several small inconsistencies and >>> typos in the >>>> draft 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 the >>> right time to >>>> start 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/p2psip >>> >>> >>> _______________________________________________ >>> P2PSIP mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/p2psip >>> >> > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
