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
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
----- Original Message -----
To: "todd glassey" <todd(_dot_)glassey(_at_)worldnet(_dot_)att(_dot_)net>
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
head. The IETF is still predominantly Engineering Staffers and the
has evolved to a point where it now needs Commercial input too. The lack
commercial input into the IETF is clearly a statement of the IETF's
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
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
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
and now more than ever these need to be governed or certified by
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
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
killed them (our toys) as such. What that meant is that the solutions we
RFC2026, section 4.2.4.
TSG: My point exactly.