ietf
[Top] [All Lists]

Re: Voting (again)

2005-04-15 11:30:48

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.

That is wishful thinking on your part, not reality.

Design by committee tends to wreck as much as it improves.

You want design by individuals or small committes with input and
feedback from larger communities.  

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. 

No, my concern is producing good designs, which is not the same thing
as an absence of mistakes.  Mistakes in good designs can be corrected.
Mistakes in poor designs are not self-correcting because the design
is too broken to correct them and if the design gets widely deployed,
there's too much investment in the design to start over.

If the standards process is responsive you can discover the
mistakes quickly and move on.

The standards process that we have is fairly good at fixing small
mistakes, not so good at fixing design flaws.
 
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 
problem.  

If I want folk with varied concerns I talk to users, not engineers.

You want to talk to both.  Experienced engineers understand what it
takes to make a design successful and if you have engineers with 
a variety of experience it's more likely to be successful in a 
variety of scenarios.  Users have a different perspective which is
also valuable - provided, of course, that there are already users
of something resembling whatever you're trying to create.

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 
isolation
- 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 is not an elite engineering forum.  It's a self-selecting
engineering forum.  We have some good people here (still) but
we're not nearly as good at attracting especially talented 
engineers as we need to be.

Of course the reason you want good engineers is so you can draw
on their experience.

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. 

That's a circular argument, and it's also incorrect. IETF's imprimatur 
affects early deployment as least as much as late deployment.  Once 
there's critical mass behind some protocol, it's very difficult for
IETF or anyone else to change the direction the market is going -
even given tremendous technical advantages for the new direction.
IETF can try to adopt or revise that protocol but it can't always
fix inherent flaws in that protocol.

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'. 

Yup, and that's the right order.   But in the absence of critical mass
behind a single solution, of several competing solutions that claim to 
work, one that is a standard will typically be favored, and for sound 
reasons.

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
standard?

HTTP is a draft standard.  In practice that seems to be good enough
for almost everyone.  Hardly anyone inside or outside of IETF is 
really concerned that HTTP isn't "full" standard - in practice, that's 
just an ego thing.  And the process that got HTTP to draft standard
was valuable - as messy as HTTP/1.1 is, it isn't nearly as bad
as what "the market" was doing to HTTP without review.  The reason 
HTTP isn't full standard is that the perceived gain isn't worth the 
perceived effort. Are there significant improvements that need to 
be made to the specification (that wouldn't require a recycle at 
proposed or draft)?  Will making HTTP a full standard increase 
the market acceptance? No and no.  As I said, it's just an ego thing.

To give a concrete example, does anyone believe that CSV+IETF
imprimataur has a hope of displacing SPF/Sender-ID with no
imprimataur?

It's a mistake to view this as an either-or question.  The thing to
do is to allow multiple schemes to coexist.  Layered defense.
The market might try to deploy either or both  of these, but neither
one is going to be very useful by itself in its current form (or 
I should say, as of the last time I reviewed them, which was 
a few months ago).

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.

Yep, those are problems.  Dealing with them is an art.  Voting will not 
help.

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.

Not being familiar with the particulars of such mandates, I can't
comment on them.  But those are process issues, and we have ways of
dealing with them.

Also, I'm not very impressed with SOAP, and only slightly more impressed
with BEEP.  But then again, I think XML in general is highly overrated. 
Useful yes, but overrated.

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.

I haven't seen cases like that.  I've actually seen a lot more cases
of single-vendor coercion.  Everybody's experience is different, I
suppose.

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.

I've also seen cases where the chairs refuse to acknowledge technical 
realities because the self-appointed stakeholders were applying 
pressure.  Chairs make mistakes.  And the last thing we need is a
structure where self-appointed stakeholders can impose mandates.

One person's stakeholder is another person's oppressive monopoly.

IPSEC should have supported NAT from day one.  

If memory serves, IPsec (or at least the idea of IPsec) predated NAT
by many years.  And as far as I can tell, almost everything IETF has
done to support NAT has been harmful.  I do think that IPsec got 
stuck in the mode of thinking of "IP address = host identity" and
that in hindsight this was a bad idea for lots of reasons which have
nothing to do with NAT.  But it was how nearly everyone thought back 
then.

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.

It _was_ desirable to suppress NAT.  NAT is a disaster and support
for NAT was correctly seen as shortsighted.  IETF's mistake,
in hindsight, was not making transition issues paramount in the
design of IPv6.  In hindsight, IPAE looks a lot better now than it 
did at the time.

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. 

I would have had the same objections no matter who made the proposal,
and no matter what vendor was running the root or major TLDs.  If it
helps your ego to think this was a personal attack against you or your
employer, fine, you are welcome to your delusion.  But to make that
statement in a public forum is, if I'm not mistaken, slander.

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.

Sorry, I don't buy into your world view.

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 need.

That's right.  But if you don't get relief you go to the IAB.
 
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 
employees elect their managers?  Do you think that would be a good
way of  choosing people who would carry out the organization's 
strategic goals?

I don't consider the ADs managers. 

Then you don't understand what ADs do.

The IETF is the only institution I have ever encountered that has such
a deficit of accountability.

You seem to think that the IETF isn't accountable because they make 
decisions that you don't like.   I assure you from having been there
that there is significant pushback against IESG people who do things
that WG participants don't like.  Appeals are painful enough for 
everyone on IESG that even the implied threat of appeal is a
powerful incentive to craft a compromise.

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

Nope, because nowhere nearly that many people would vote even in
IETF-wide elections.  Or if they did, their votes would be meaningless.
there are far fewer than 1000 people who actually would know who
they were voting for or why they should pick one candidate over
another.  Under those conditions, it's easy to manipulate
an election, and you're not likely to get good selections even if
the election isn't manipulated.

 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 million.

And there are a few companies that would pay a significant
fraction of that if they could dictate the outcome.
 
I could see a place for voting in some things - like choosing 
people who decide or oversee how the organization's money is 
spent, and maybe in choosing ombudsmen who would help in dispute 
resolution. I don't think voting has a place in IETF's technical
decision-making.

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.

This is one of those "reality" arguments again, isn't it?  Meaning
that you get to claim that your version of "reality" dictates some
poor technical decision?  I've got news for you - "reality" is
neither objective nor immalleable.
 
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. 

It's even better to deploy a good spec, one which is well designed
and adaptable without disruption.  Of course, part of the problem with
trying to make TLS sane was trying to be backward compatible with
the broken spec that was already out there and which didn't have
a reasonable upgrade path.   I'm not saying that SSL should have 
waited until it was standardized before people started deploying it,
I'm saying that standards can't always fix things that are broken
once those things are widely deployed.

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.

That's a very narrow view.

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.

I suspect your notion of success doesn't coincide with mine.  At any 
rate it's meaningless to compare success of one standard with another
unless those standards more-or-less serve the same purpose.

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.

And it's a really good way to screw those who will be adversely 
affected by the WG's output but who can't afford to attend every 
meeting of very WG that will affect them.  

Keith

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf


<Prev in Thread] Current Thread [Next in Thread>