These are not mutually exclusive, and the last point is more
dubious than the first two. While deployment is a necessary
condition for success, so is technical soundness. Our
broader purpose is not just to create new protocols - it's to
keep the Internet working well.
Technical soundness can be dealt with in Darwinian terms.
Design by committee tends to wreck as much as it improves.
Your concern is to avoid mistakes, my concern is the paralysis that
affects the standards process. I don't worry very much about mistakes
because most are self correcting, people do not usually implement broken
specs. If the standards process is responsive you can discover the
mistakes quickly and move on.
On the contrary, there are very many occasions where the way
to understand the solution space to a problem is to involve a
large number of people with varied concerns related to that
If I want folk with varied concerns I talk to users, not engineers.
You don't want so many people involved in the
actual design - but you do want them in on the problem
definition and to provide feedback to design proposals.
I've seen very few occasions where a design that was done in
- even by very intelligent people - held up well on the Internet.
That's is a good point but why do you think that an elite
engineering forum would be a sensible place to achieve that?
IETF's imprimatur does have an effect, in the sense that if there's a
perceived need for a solution to some problem an IETF
document is more
likely to be seen as _the_ solution than a competing solution
from, say, a vendor.
Only once deployment has reached the critical mass point.
The market already understands the open standards issue to the point of
obsession. But the issue is really one of change control. The first
question people ask is 'does this work for me', not 'is it a standard'.
It takes so long to obtain the IETF imprimartaur that the success
question is settled by the time the imprimataur is received. Perhaps
HTTP will be recognized as a standard sometime, but I doubt it. It
should take the IESG what, five seconds to agree that HTTP is a
To give a concrete example, does anyone believe that CSV+IETF
imprimataur has a hope of displacing SPF/Sender-ID with no imprimataur?
The real point of a working group process is to establish the
coalition of support you need to get the work deployed.
I strongly disagree. And treating this as the real point of
a WG is a good way to produce garbage. What is really needed
is a balance - get the right people on board to produce a
good solution that meets a wide variety of needs, AND who
will help get the result deployed. That's not the same set of
people, but often there is some overlap.
I don't have any problem with either group you mention. The problem in a
WG is when you get visited by rock throwers or zealots who have a
completely different agenda, or some other group that wants to get their
standard deployed by making it a precondition for a spec that has a lot
of public momentum.
We still have WGs being told that they have to support BEEP, despite the
fact that it is inadequately engineered as a web services transport, has
been decisively rejected by the market as a web services transport and
is based on obsolete technology. SACRED was bounced into making BEEP
their transport despite the fact that the spec only makes sense as an
adjunct to SAML and XKMS which are SOAP based. The RID spec was made
worse by the insistence on support for BEEP.
Why is a 'standards' organization enforcing this Not Invented Here
attitude? If you look at what every Web Services platform supports, both
commercial and FOSS the only conclusion that is possible is that BEEP
should be moved out of standards track and considered obsolete.
The SOAP work won because it is supported by a much wider coalition of
vendors and developers. It established the necessary support. BEEP was
fast tracked through IETF in a transparent attempt to try to pre-empt
SOAP. It is a failure because the WG did not have any of the Web
Services platform developers participating.
People will say to
themselves, if the FemtoSoft or TransCo guy is that opposed to this
proposal, it doesn't have a chance of being deployed, so I'm
going to withhold my support also. I've seen it happen lots
of times. I'm
very opposed to giving FemtoSoft and TransCo more votes than
anyone else but I don't have a problem with individuals
considering that certain contributors input carries more
weight than others.
Which is the same process I see.
Yes there are occasions in which you get a company that has some evil
vendor scheme going on, I have not seen many cases where this has
But I have seen many cases where a group of rock throwers or zealots
have decided to visit a group with the sole purpose of 'sticking it' to
some vendor they dislike for some reason.
In my book people who actually write code and deploy code have a
rather bigger say in the typical decision than those who do not. If
someone makes a proposal and the authors of the six major
implementations and all the ISPs in the room vote against
it then in
my view the proposal isn't happening regardless of what the
'consensus' might be.
And in all my IETF experience I've never seen anyone declare
when the authors of six major implementations and all of the ISPs in
the room were opposed to it.
We have both seen cases where the chair has refuse to acknowledge the
need to change a spec in order to support real world constraints that
affect key stakeholders.
IPSEC should have supported NAT from day one. IPSEC makes a dreadful,
lousy VPN protocol because it does not support NAT properly. But it was
only after several years of complaints and a revolt by the vendors that
anything was done about this.
I remember very clearly Steve Bellovin saying to the IPSEC WG that the
IPSEC proposal as then defined would not support NAT well but that some
folk would consider that to be desirable.
Five years ago you were one of the people who argued that it would be
better not to deploy DNSSEC than make the changes I was proposing. You
were successful in sticking it to a vendor you dislike. And the Internet
is the worse as a result. If my advice had been taken then DNSSEC would
be deployed now and people would be adopting it to avoid the DNS based
phishing attacks that are taking place.
When chairs do abuse their positions, there's a process for
that. I do think that we have too many cases where chairs
are also document authors so that there is an almost inherent
conflict of interest.
The process is to complain to the unelected AD who may not be too happy
challenging a WG chair who is also an AD and whose support he might
Why can't we elect the WG chairs? Why can't we elect the ADs?
Say for the purpose of argument you're running a business, or
maybe a large non-profit organization. Would you let your
their managers? Do you think that would be a good way of
choosing people who would carry out the organization's
I don't consider the ADs managers.
In OASIS, Apache, most FOSS projects we elect the oversight boards, in
W3C we elect most of the oversight board and it is pretty clear that any
director that succeeds TBL is almost certain to lose the appointment
privs that the director currently has.
The IETF is the only institution I have ever encountered that has such a
deficit of accountability. Even the US universities have moved to having
student representatives on most boards.
The last thing that iETF needs is to let organizations buy votes by
having their employees become members or sending them to meetings.
There are about 1000 people who qualify for Nomcon. To influence a vote
a company would need at least 300 people and plan their approach a year
ahead. The cost of each vote is 2 * ($600 + airfare + 1 weeks pay +
overhead). That's at least $5000 per vote if they send secretaries
along, $10K for an engineer. So to have an effect it would cost about $3
I don't think that vote packing would work here. The only time I have
seen it in other standards orgs is when patents have been involved and
someone is trying to get a patent embedded in a standard. I see that as
a function of weak IP controls.
I could see a place for voting in some things - like choosing
people who decide or oversee how the organization's money is
maybe in choosing ombudsmen who would help in dispute
resolution. I don't think voting has a place in IETF's
I don't think that you vote over whether the earth is round or flat.
But it is useful sometimes to have a vote to say that it is not worth
discussing the round/flat issue any further.
My problem with WG processes is where you have the flat earth faction
coming back to the table again and again to argue the case long after
the time has passed.
If a group of loosers get together in a room they will produce lossage.
I don't worry about that because lossage has a short lifespan. Even in
the security area the evidence of SSL 2.0 and WEP demonstrate
conclusively that it is much better to deploy a broken spec than wait
for perfection. Mistakes are bad but if the D-Team do manage to get
something out into the market and used the A-Team will be along soon
enough to fix it.
If you had tried to identify the parties whose buyin were
needed to deploy IPsec and IPv6 you'd have gotten it wrong.
My first meeting might not have the right people at the table but my
third always has.
In both of those cases a big part of the reason for the delay
is that the people developing the protocols didn't understand
their target market. (this may still be the case to a large
degree) And it's not because the presumed-to-be major
players weren't involved, it's because the participants
didn't fully understand and anticipate how the Internet was
changing. Voting wouldn't solve that problem.
The major players are not the vendors, they are the backbone carriers
and the ISPs.
The way the system works in OASIS is that there is a con call every
week or two weeks and members of the group have to attend the con
calls to maintain voting rights.
That's a really lousy way to ensure broad input and a really
good way to make sure that the group works in isolation and
produces irrelevant output.
SAML was produced in less than a year and has been considerably more
successful than most IETF specs produced in that period.
Actually the process has the reverse effect. People attend WG meetings
to keep their voting rights. Instead of four people carrying the WG
there are 40 or more.
Ietf mailing list