Hmmm. Adding a forward reference in 3.5 is trivial. I don't know about moving it, though. There are so many different things that can be in the overlay configuration file, and I think that makes a lot more sense to keep it with the rest of the discovery/enrollment issues. I think you could make more of an argument to move all of 11 earlier in the draft, though I'd have to think about that for awhile.
Bruce On Tue, Feb 10, 2009 at 10:56 PM, Dan York <[email protected]> wrote: > Ah, so it is... thanks for the pointer, Bruce. I did indeed miss something > fundamental in the draft. > > Could I suggest that in the base in section 3.5 there is a line of text > added along the lines of: > > ------ > The Topology Plugin is described in further detail in the section on > "Overlay Topology". > ------ > > Or something like that to clue other readers in about the section to jump > ahead to? > > Also, why is section 11.1 with the "Overlay Configuration" separated so far > away from the pieces related to the overview topology in section 5.3? > > Might it not make more sense to have section 11.1 as a subsection of 5.3 so > that it is right there with the other info about using alternate topology > algorithms? > > Thanks, > Dan > > On Feb 10, 2009, at 11:52 AM, Bruce Lowekamp wrote: > >> 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 >>> > > -- > 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
