The IANA section also has Overlay Algorithm Types registry Roni Even
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Bruce Lowekamp Sent: Tuesday, February 10, 2009 6:53 PM To: David A. Bryan Cc: [email protected] Subject: Re: [P2PSIP] Interoperability vs Pluggability (was Re: mobile p2p in p2psip) the algorithm is specified as "topology-plugin" in the overlay configuration. http://www.p2psip.org/drafts/draft-ietf-p2psip-base-01a.html#sec-configuration Bruce On Tue, Feb 10, 2009 at 11:08 AM, David A. Bryan <[email protected]> wrote: > 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 > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
