There is a motivation you forgot. It is to take control of your particular
part of the world in using the IANA to lodge your vision and/or your name.
Like a micro TLD Manager.
This goes beyond impressing your commercial/political relations in having
signed an RFC in their area - what you quote as the second motivation. You
become a permanent acknowledged part of the core of the Internet
metastructure. A part of the Internet Nobility. A new Larry Robert, Doug
Engelbart, Louis Pouzin, Jon Postel, Vint Cerf ....
At 00:43 13/04/2005, Hallam-Baker, Phillip wrote:
Reading through the comments on voting I am struck by a difference in
the approach people take to what the IETF is for.
* One school of thought is that the reason for starting a working group
is to arrive at a better engineering outcome than is possible
* Another school of thought is that the endorsement of a respected body
will lead to deployment
* The position I do not see argued is that the point of a working group
is to establish the constituency required to deploy the proposal.
As far as the first two positions go, I have made the mistake of
beleiving in them in the past. These days I recognize that there are
very few occasions where the way to arrive at an optimal solution is to
get a group of 40 people together to work on it. WG process improves
proposals in some respects, and is particularly valuable in ensuring
that there is some sort of consistency in the general approach. But
there are also serious negatives, a WG spec will inevitably be larger
when it exits the working group and while the result is more likely to
be consistent with legacy work the level of internal consistency will be
I don't think that the imprimataur effect exists, if it did we would all
be using IPv6, IPSec and DNSsec. And this problem is not limited to
IETF, the ITU, W3C and OASIS all have the same issue. If you have a spec
that has already established a critical mass a standard can help
increase the size of the final deployment constituency. But that is not
the hard part, the real hard part is getting to that critical mass.
The real point of a working group process is to establish the coalition
of support you need to get the work deployed.
And this has to be taken into account when you are considering votes.
All a hum tells me is who makes most noise. If I am sitting in a WG
meeting and I vote for a particular proposal then the meeting knows that
I have a level of commitment to that proposal. If the group votes the
other way and I stay in the group even so there is another data point.
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.
The other really big problem with hums is that they can be very
corrosive of trust in the chairs. The vote might have been in favor 40
to 10 and the chair assesed the hum as in favor and ten people still go
to the bar thinking that the system is rigged. Hums lack auditability
and as recent experience of machine voting in several countries has
demonstrated auditability is the single biggest issue for a voting
system as far as most voters are concerned. Large scale intimidation is
pretty easy to pick up.
The problem is even bigger when the chair decides to abuse their role.
Why can't we elect the WG chairs? Why can't we elect the ADs? I feel
absolutely no responsibility or duty towards officials that I have no
part in electing and I don't think many other people do. There is a
reason why the IESG is generally treated as if it was some sort of
politburo, that is how people will relate to a body that is formed by a
proceedure whose clear purpose is to distract the masses. The problem is
that the IESG is not made up of Vint Cerf, Jon Postel and co any more.
If people want to deploy IPv6 or IPSec or DNSsec or any of the other
decades overdue technologies the IETF has grown infamous for delaying
the only way it is going to happen is to hold a meeting with the
stakeholders whose buy in is needed to deploy and to negotiate.
Contrary to what some people believe the problems are not going to be
solved by a more perfect document. Nor is refusing to hold such a
meeting under IETF auspices going to stop such meetings happening, in
fact they are going on already and the IETF is not being invited.
The biggest problem with 'voting' is the tourism factor. A group can
have a carefully worked out possition on a topic and then have it
wrecked by a group of people coming into the room because they have
heard about 'the issue' through the totally unbiased and accurate lens
of a story on Slashdot.
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 system works really well, there is only one
occasion that I know of where a group of wreckers were organized well
enough to sink a rival group and that did not profit them any because
the group simply decamped to another forum.
The fact that people can leave and take their ball with them is the
thing that makes the standards process work. It is absolutely not a
failure of process that a group whose idea is rejected by the IESG can
go off and work on it elsewhere. It is the only check to balance the
The real point of voting is legitimation. Voting on protocol design does
not make a good deal of sense but as Churchill observed (quoting
McCaullay) it is better than the alternatives. Allowing the chair to
impose their own opinion does not make much sense either.
Ietf mailing list
Ietf mailing list