Hi Henry, > 3. An editor is required
Ultimately, the chairs may decide that an editor is appropriate, but certainly we're willing to continue to do the work. > * Remove the tutorial part and just reference some of the 1,000s > of papers on P2P and DHT. I think it's a really tough call how much tutorial should be in here and how much should be somewhere else. You're right that we should have informative references to a few more papers (there have been more in some prior drafts), but that doesn't serve the same purpose as the conceptual overview. Our goal has been to make the draft reasonably stand-alone, so that it could be given to a network engineer who is implementing the protocol and they can understand the key concepts. Sure, I like reading the Kademlia paper in raw form, and I actually have a copy of Rhea's dissertation on my desktop right now, but I don't want a programmer to have to understand it from that source. > > * Use common technical terms and avoid confusion. For example > the notion of P2P connection in the draft: I believe the writer meant > long hop neighbors and near neighbors (leaf set). Also, routing state > means the routing table + the neighbor tables. If in doubt, the > Wikipedia and openDHT have very extensive text on this. > Again, this is a hard line to follow. We're trying to use terminology from p2psip-concepts and use terminology that will be consistent with the rest of IETF practice. While we try to use terminology from the literature when appropriate, it isn't always there, it may conflict with other ietf terminology, and it isn't always consistent. But if you have terminology you think we should be using, by all means bring it up as a suggestions for the concepts document. Regarding the connection, in particular, I think the term you are referring to has more to do with the establishment of a link between two peers (forming an edge in the overlay network) and use of that term in the draft dates back to p2psip-dsip-nat-traversal that Eric, Philip, David, and I worked on. The discussion of what the connection table is may not have carried forward as well, though... > > > 4. Discussing design decisions > > Obviously these technical decisions will continue to be rehashed by the group once a protocol document is adopted, but many have been discussed extensively on list. > > * Symmetric routing has been criticized on the list already, but > never discussed. It seems to me a bad idea (and I can argue why) > Please refer to the "Routing mode in P2PSIP" thread from November 20-26, 2007. Other forms of routing can be used as an optimization in many circumstances, but it's complicated to determine when they can be used. Symmetric is needed for overlay healing and nat traversal situations. I think there is still room to say more on this topic, though, and the decision of efficiency vs complexity is always a tough one. > * I would also like to understand for example why Via and GRUU > are proposed and exactly how it would work here > > Especially via seems to duplicate SIP routing with the underlying DHT > routing - or does it? Please explain. > The via list concept is key to allowing client nodes to participate and to reduce the state required of peers when performing symmetric routing. If you were to route SIP messages across the DHT, I wouldn't expect overlap because the peers wouldn't be modifying the SIP message, they'd be modifying the peer protocol message. You're right that this concept still needs more explanation and examples. > I believe a fair technical process is critical to a successful P2PSIP > and to avoid having winners and losers and unhappy campers who feel they > may better ignore this emerging standard. I'm sure I speak for all the authors when I say that we're very interested in receiving any technical criticism or suggestions that will make this a successful protocol. Bruce _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
