In response to the letter below: Vladis - you are wrong in my opinion. Your response seeks to minimize the issues and they are just not going away. And I have some news from the real-world for you... Letting a technologist blindly develop a protocol that is supposed to work in a commercial world is in my opinion more dangerous that allowing the salesperson to design a protocol for the technical world to solve a problem that they are faced with on a daily basis. Especially as the IETF moves more and more into user application protocols and away from core backbone routing and communications protocols... More inline below Todd ----- Original Message ----- From: <Valdis.Kletnieks@vt.edu> To: "todd glassey" <todd.glassey@worldnet.att.net> Cc: <ietf@ietf.org> Sent: Thursday, April 18, 2002 9:01 AM Subject: Re: How many standards or protocols... On Wed, 17 Apr 2002 21:02:08 PDT, todd glassey said: > Actually James you have to a big extent hit the cause of the problem on the > head. The IETF is still predominantly Engineering Staffers and the Internet > has evolved to a point where it now needs Commercial input too. The lack of > commercial input into the IETF is clearly a statement of the IETF's concern > about being told what it can and can't develop... and to date the IETF has > long survived by saying "We know better, we are the technical gurus". But > this is inaccurate and a smokescreen these > days. You can be as great a salesman as you want, but you still can't design a stable feedback loop that responds in less than 2*RTT across the system. You don't let salespeople design bridges or cars or toasters either. There's nothing wrong with a salesperson saying "It would be really great if there were a protocol that let people do XYZ easily". But unless they actually know something about protocol design, they shouldn't design it. TSG: But isn't the requirements document most of the design in most instances? If you cant define the need then the protocol definition is at best speculative and ambiguous. > The other side of the coin is different though. These are End-User Protocols > and now more than ever these need to be governed or certified by commercial > acceptance... before they get to the point of being a proposed standard. OK.. So it should succeed in the marketplace, and *THEN* be standardized? TSG: perhaps. But I am not clear that the IETF should produce anything other than recommendations. That Internet Standards and anything above an RFC is fodder for a more regimented and audited group. 1) Once it's a success, why should the company turn over change control? Sure, Sun did it for NFS, but that was many years ago, and many people were surprised that they did so. Do you see any good reason why Sun would do that with Java, or Microsoft do it with their .NET stuff? 2) The time for there to be a *full* review of a protocol for things like scaling and security issues is *BEFORE* it gets widely deployed. Go look at WEP or Microsoft's first version of a point-to-point solution. TSG: But who here in the IETF has done commercial security analysis or legal analysis of what the use models for a Protocol does? > The problem as I see it is that the Engineer (or child) in us is frightened > by this, since traditionally the commercial folks (the adults) have driven > home that no matter how cool our inventions (or toys) are, there may in > fact be no commercial use for them... and they, in the interest of Business, > killed them (our toys) as such. What that meant is that the solutions we RFC2026, section 4.2.4. TSG: My point exactly. Todd