Re: how to fail to solve a problem
Keith Moore wrote: > p.s. OTOH it does seem foolish to try to make fundamental changes to IETF > by arguing on this mailing list. the organization is very wary of change > of any sort, and rightly wary of half-baked ideas. about the best you can > do with this list is to find folks who are willing to cooperate (in a less > public venue) to examine and develop the idea more fully. I am a fan of half-baked ideas. I am a fan of post-optimization. Get it close to the bull's eye and throw it out there. The ensuing discussion will refine it, or kill it. Isn't that how we pride ourselves in Internet development? But we must also understand that this process does not always converge, and does not always converge to a desired solution when other protocols are taken into account. So, a degree of oversight is needed -- and the least intrusive oversight, I think, would be to make non-conformance public. And, for that matter, non-interoperability. And, lack of security. Now, of course, some still believe that making security flaws public is a security flaw. The "prove me wrong, go to jail" approach. Cheers, Ed Gerck
Re: how to fail to solve a problem
> > p.s. OTOH it does seem foolish to try to make fundamental changes to IETF > > by arguing on this mailing list. the organization is very wary of change > > of any sort, and rightly wary of half-baked ideas. about the best you can > > do with this list is to find folks who are willing to cooperate (in a less > > public venue) to examine and develop the idea more fully. > > I am a fan of half-baked ideas. I am a fan of post-optimization. Get it close > to the bull's eye and throw it out there. The ensuing discussion will refine > it, or kill it. Isn't that how we pride ourselves in Internet development? I'm not interested in how we pride ourselves. I'm interested in what works. Having pride in a particular way of doing things is a good way to be blind to its faults. One common way for an idea to be half-baked is for it to utterly fail to consider the needs of some constituency or another. As the Internet has become larger and more diverse our organization has also become fragmented, its participants representing very diverse interests. Probably for this reason it's become fairly common for working groups to produce results that are half-baked in this way. Throwing such half-baked ideas to the marketplace usually hasn't resulted in refinement, but it has resulted in harm to the Internet's ability to support new applications. And by the time the harm is understood, it's way too late to kill the bad idea. As for making non-conformance public, I would very much like to see that happen. Whether IETF is in a good position to do this is a different question. Since (perhaps unfortunately) most of IETF's energy comes from vendors who pay their employees to work within IETF working groups, and some of those same vendors have reputations for producing dangerously non-conformant implementations, I think it puts IETF in a precarious position if it starts pointing fingers at the vendors who produce such things Keith