I have a feeling I'm gonna regret getting involved in this rat-hole, but
here goes anyway...
I mostly agree with the "let the market decide" philosophy, but there have
to be some limits. Following this strictly leads to pathological cases. To
point out incidents from the IETF PKIX group over the years that demonstrate
what can happen:
1 - a gentleman (I'll be polite and call him that) asked PKIX to adopt
as a
work item a time-stamping technology he developed. This gentleman was given
an opportunity (at Adelaide and I believe at one other meeting, as well as
on the list) to present his material to the working group. In the end, PKIX
didn't pick up his work as a work item because it didn't fall under the
charter of the WG. A total of only about 3 people even thought it was
interesting, and they weren't sure it was within the working group's
purview.
This gentleman has devoted much energy since then to disparaging the
IETF,
PKIX, and the PKIX WG chair personally, for this. His view, stated in
public numerous times, is that the way the IETF should work is that any item
which is properly formatted must be published as an RFC. That is, any
individual or group can create a document. If it meets the formatting
requirements, it must be published as an RFC. It is not the job of the WG,
the IESG, IAB or any other group to approve/disapprove, evaluate, analyze or
otherwise pass judgement on the technical contents of the document.
Furthermore, all RFCs must be given the same status. It is not
appropriate
for the IETF to favor one RFC or the technology contained in it over any
other RFC or technology.
Any other strategy constitutes restraint of trade, interference in the
market place, and basically a violation of all that a "standards group"
should do.
Now, fortunately, not too many people agree with this gentleman, but it
does represent a pathological case of "let the market decide".
2 - the PKIX WG published two competing, non-interoperable protocols for
the same function. One is referred to as CMP; it's in RFC 2510. The other
is referred to as CMC; it's specified in RFC 2797. There are a lot of
reasons why we did this; but it boiled down to a schism. One of the two
largest PKI players at that time preferred CMP, and its allies refused to
yield. The other of the two largest players preferred CMC, and its allies
refused to yield. This was because those protocols represented what their
products did, and nobody wanted to change his product. So, to prevent
bogging down and making no progress at all, the WG decided to progress both
protocols and "let the market decide". Most people now agree that this was
a mistake. The strategy of publishing both protocols as "equals" did not
lead to interworking in the Internet; it arguably did the opposite. It was
also horribly misunderstood by those not in the know; it was believed in
some quarters that one protocol was the interim strategy and the other was
the long-range target. (The supporters of each side did nothing to
discourage this misunderstanding.)
While this is not the biggest factor in the failure of PKI to become
ubiquitous, it didn't help.
My bottom line on this: while I'm not a strong believer in having the
cognoscenti dictate to the unwashed masses the "one true way to do things",
it helps a lot if the Internet Engineering Task Force actually does some
"Internet Engineering".
Al Arsenault
-----Original Message-----
From: owner-ietf(_at_)ietf(_dot_)org [mailto:owner-ietf(_at_)ietf(_dot_)org]On
Behalf Of
Christian Huitema
Sent: Sunday, October 12, 2003 1:59 AM
To: Keith Moore
Cc: ietf(_at_)ietf(_dot_)org
Subject: RE: accusations of cluelessness
It is perfectly fine to review a specification, understand the
intent of
the original designer, and suggest ways to better achieve the same
result. That is exactly what working groups are supposed to do. It
is
also perfectly fine, if the original designer won't change their
design,
to publish an alternative design that hopefully works better, and
then
rely on market forces to sort it out. But it is not fine to try to
prevent the original designer from actually shipping products,
either by
preventing publication of the specification or by trying to prevent
deployment.
On the contrary, it is our duty to do all of these things.
What is not fine is for participants to expect IETF to lend its
support to
bad designs.
Well, who made us kings? It is one thing to work and publish designs
that hopefully will be good. It is quite another to judge someone else's
design and brand it bad. It is far better to let the market be judge.
-- Christian Huitema