All valid points, Kerry. I want to be clear, though, that I'm not arguing the IETF protocols are technically superior to homespun solutions. In some cases they are, in some cases not. I also agree they typically take more time to implement, often significantly more when, as you say, you have to pull in another 100 RFCs to get the functionality you want.
I am convinced, though, of the power of interoperability. I go back to HTTP all the time and have pretty much beaten that argument to a pulp, but HTTP enabled the vast majority of what we call the Internet. It's certainly not the most technically dazzling protocol out there, but the fact that it's a standard allowed everyone to talk to each other and for everyone to build creative services on top of it. I really think the reason we haven't seen a similar flourishing around some of the newer protocols is that they're still too new and not as well understood. As the web continues to mature, I expect the need to standardize on some way of doing a bunch of these things (NAT traversal, media exchanges, etc) to grow more apparent. Heck, I could be wrong, but that's my reading. -Adam On 9/12/07, Kerry Bonin <[EMAIL PROTECTED]> wrote: > > Thought I'd toss in my two cents on IETF vs. what most of us are doing, > since I deal with standards all the time, and regularly interact with some > well funded research groups that play in the same space. > > IMHO one of the ways in which the IETF protocols are far less interesting > in practice is their desire to use many standard protocols together as the > 'correct solution' instead of stepping on each others turf and trying to > combine them. As listed below - STUN + ICE + SIP + ... Add the complexity > and ambiguity of the specifications, lack of quality, unencumbered reference > implementations, and contrast it with the elegance possible if you simply > learn from these protocols and assemble your own that borrows the best of > each. > > I faced this same dilemma when building my current transport protocol > engine - I needed DOS resistance (client puzzles) right up front, ECDSA with > one and two way cert exchange, session key management, encryption + MAC, all > over UDP with parallel virtual channels with different delivery options per > channel ranging from unguaranteed to ordered/guaranteed and with delivery > notification options. Add NAT management on top (STUN, relays, ect.) > > Do you know how many IETF protocols I would had to bolt together to get > most of that feature set, and how big and complicated the resulting codebase > would be? And a simple requirement like client puzzles up front breaks most > standards, in any case, as does a simple requirement to operate over a > single random port number. > > This is one of the biggest reasons why most of us roll our own. The IETF > groups are performing great research in their niches, but the protocols > themselves are rarely useful outside of their testbeds. On the other hand, > they make great reference reading, to see what use cases and solutions the > researches have documented, especially when those use cases match data we've > collected from the field. > > Kerry Bonin > > > David Barrett wrote: > > I disagree with Michael's assessment of the motivation of IETF > participants; everybody I've met appears to have the best of intentions. > > > > My concern is the real world always seems like an unwelcome guest in IETF > discussions, and I constantly feel like an ass for harping on things like > data, implementations, actual use cases, etc. > > > > Regardless, I'm eager to hear your (forgive me) real-world results > implementing the IETF P2P stack (STUN/ICE/SIP/etc). The proof is in the > pudding, so let's eat! > > > > -david > > > ------------------------------ > > *From:* [EMAIL PROTECTED] [ > mailto:[EMAIL PROTECTED]<[EMAIL PROTECTED]>] > *On Behalf Of *Adam Fisk > *Sent:* Wednesday, September 12, 2007 10:11 AM > *To:* theory and practice of decentralized computer networks > *Subject:* Re: [p2p-hackers] Best NAT traversal options > > > > Right. I forgot I'd seen you over on some of those lists. I'm surprised > you participate if you think it's all about commoditizing the competition or > gumming things up, though. Which one are you doing? Joking joking. > > No, I agree the IETF has problems, but some standard emerging out of the > p2p hackers list sure would scare me a lot more! > > -Adam > > On 9/5/07, *Michael Slavitch* <[EMAIL PROTECTED]> wrote: > > For those that need help with that, try this: > > http://www.google.com/search?&q=slavitch%20IETF > > On 9/5/07, Michael Slavitch < [EMAIL PROTECTED]> wrote: > > Yes, I know about the IETF. Google is your friend. > > > > > > On 9/5/07, Adam Fisk <[EMAIL PROTECTED]> wrote: > > > > > Do you know many people who work in or with the IETF? Have you worked > with > > > the IETF? I'm sincerely asking, because I would be surprised if you > had and > > > continued to hold your views. They make decisions by "taking a hum" > for > > > Christ's sake -- similar the yeahs and the neighs (sp?). These people > are > > > the enemy? To me, it's a miraculous example of cooperation amongst > > > frequently competing interests. > > > > > > -Adam > > > > > > > > > > > > On 9/5/07, Michael Slavitch <[EMAIL PROTECTED]> wrote: > > > > > > > > "The IETF is really not so different from this list -- a bunch of > > > > people getting together to make stuff work." > > > > > > > > Not so sure about that. > > > > > > > > The goal of participating in a standards body to either make things > > > > work to commoditize the competition or gum things up so that they > > > > never work, are horrendoes to implement, thereby creating barriers > to > > > > entry that only you can exploit. > > > > > > > > Look at IMS, for example. > > > > > > > > How easy is it to get ICE working, and I mean >working<, not > "working". > > > > > > > > How long has it taken to develop and finalize? > > > > _______________________________________________ > > > > p2p-hackers mailing list > > > > [email protected] > > > > > > > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > > > > > > > > > > > > _______________________________________________ > > > p2p-hackers mailing list > > > [email protected] > > > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > > > > > > > > > > > -- > > Michael Slavitch > > Ottawa Ontario Canada > > > > > -- > Michael Slavitch > Ottawa Ontario Canada > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers > > > > ------------------------------ > > _______________________________________________ > p2p-hackers mailing list > [EMAIL PROTECTED]://lists.zooko.com/mailman/listinfo/p2p-hackers > > > > _______________________________________________ > p2p-hackers mailing list > [email protected] > http://lists.zooko.com/mailman/listinfo/p2p-hackers > >
_______________________________________________ p2p-hackers mailing list [email protected] http://lists.zooko.com/mailman/listinfo/p2p-hackers
