If having a mechanism to negotiate the DHT isn't in there, it definitely is something that needs to be corrected. Going all the way back to draft-bryan-sipping-p2p-02 there were fields for specifying which DHT should be used, and a section on negotiating it (since it was SIP, it was very straight-forward -- we specified that you use offer/answer...). I'm fine with falling back to a client protocol connection, but that doesn't change the fact we need a mechanism to negotiate the DHT if we support pluggable DHTs. Failing to find a common one, you can fall back to client connection.
It may very well be there, or it could have somehow fallen out of the most recent version (can one of the authors comment?) If it did fall out somehow, it is good for people to point things like this out about RELOAD. I think when things got merged, many of the practical parts that were in the earlier drafts (at least those that were actually implemented) got unintentionally lost, or at least the descriptions became less clear as the complexity grew, and these are exactly the sorts of things that need to be corrected as we work to move forward the draft. David (as individual) On Tue, Feb 10, 2009 at 10:06 AM, Dan York <[email protected]> wrote: > Victor, > > On Feb 10, 2009, at 9:58 AM, Victor Pascual Ávila wrote: >> >>> DY> Hmmmm... so a "client" doesn't need to know the DHT algorithm to join >>> the overlay network? Perhaps I just need more caffeine this morning, but >>> I >>> guess I don't understand how any node can join the overlay network >>> without >>> understanding the underlying algorithm. I understand that a "peer" would >>> need to know this to join in the overlay and the underlying DHT, but >>> wouldn't the client also? >> >> See draft-pascual-p2psip-clients, Section 4, Argument number 4 >> >> http://tools.ietf.org/html/draft-pascual-p2psip-clients-01#page-6 >> >> Please, let me know your opinion. > > DY> Ah... so the clients communicate with the P2P overlay "peer" nodes by > way of the "client protocol". So if the P2P overlay supports such a client > protocol, client nodes can connect to the overlay without any knowledge of > the underlying DHT algorithm (or anything else in the underlying overlay > network). > > DY> Got it... thanks for explaining. > > DY> This does, of course, assume that whatever P2PSIP protocol we use would > have a client protocol. > > Regards, > Dan > > -- > Dan York, CISSP, Director of Emerging Communication Technology > Office of the CTO Voxeo Corporation [email protected] > Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com > Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com > > Build voice applications based on open standards. > Find out how at http://www.voxeo.com/free > > > > > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
