The IETF's problems

[Keith Moore]

] On zaterdag, jul 19, 2003, at 15:38 Europe/Amsterdam, Keith Moore wrote:
] 
] > some people are unhappy with the IETF because their expection does not
] > match their perception of IETF's behavior.
] 
] > or even more succinctly "some people are unhappy with the IETF"
] 
] > well, big deal.
] 
] Yes, this is a big deal. The IETF can't be all things to all people, 
] but I think it's a reasonable request for the IETF to clearly state 
] what it will do and what it won't do, who makes this dicision and on 
] what basis.

Defining IETF's scope is a good idea - if nothing else it will save energy
when we need to explain why IETF is not taking on something it considers
outside its scope.

As for who makes the decision, that's already clear from existing documents.

As for the basis on which these decisions are made, there are several
factors - technical merit, evidence of willing and capable volunteers,
availability of resources, perceived liklihood of success, and perceived
benefit to the community as a whole being foremost among them.  And these are
inherently subjective.  If it helps to write these down, fine, but they should
be obvious.
 
] > ] If people in general and large vendors
] > ] in particular come to the IETF wanting to work on something within 
] > the
] > ] IETF, and this work falls within the areas of interest of the IETF,
] > ] then it would be a very good idea that the IETF indeed work on this.
] 
] > I strongly disagree with this as a categorial statement.  Many kinds 
] > of work that people want IETF to do are not "very good ideas".
] 
] True. But the IETF still needs to work on it.

As a generalization, I strongly disagree.  (There may be specific cases where
I would agree).  But in general, we simply do not have enough resources to
work on bad ideas.  Even explaining why they're bad ideas sometimes takes too
much work.

] The same applies here: if people want to create a 
] bad protocol, there is probably some real problem that needs to be 
] solved with a _good_ protocol.

Sometimes yes, sometimes no.  Sometimes there's a real problem to be solved
and a real benefit to the community from solving it.   If we can harness that
interest in solving the problem and use it to produce a good solution, 
obviously that's a good thing.  But quite often, we are pressured to endorse
"solutions" that will only do harm.  And far too often we form working groups
to solve intractable problems, or working groups that are overwhelmingly
staffed by people who are dedicated to "solving" a problem in a technically
unsound way, in a misguided attempt to try to minimize the harm. 

] > IETF has been pressured by powerful concerns to standardize NATs, 
] > means of eavesdropping, bits in IP headers to identify porn, protocols 
] > that encourage monopolies or give one vendor a competitive advantage, 
] > protocols that  harm the Internet architecture and the ability of 
] > existing and future applications to use the Internet, and even 
] > protocols that don't interoperate (but which allow vendors
] > to claim standards compliance).  None of these are good ideas, and 
] > IETF should
] > neither invest its resources in, nor lend its imprimatur to,  bad 
] > ideas.
] 
] Obviously there are always people who'll try to exploit something for 
] personal gain. I have enough trust in both the leadership and the 
] participants within the IETF to assume these people won't get very far.

There are many more root causes of stupidity than individual greed.

] I'll ignore the architecture stuff here as this could fill a 
] mailinglist of its own. The NAT pressure seems to have been effective: 
] http://www.ietf.org/html.charters/nat-charter.html 

Sometimes the pressure does result in a WG being created, and often this turns
out to have been a bad idea.  The NAT WG has been a disaster, doing far more
harm than good.  Zeroconf is another example.

] I'm not familiar 
] with porn bits, but I can see how something like this could be 
] transformed into PICS, which is a perfectly legitimate mechanism that 
] addresses a very valid need.

People wanted to be able to filter porn on a per-packet basis.  We told them
that this wasn't appropriate, and that labelling of content wasn't our
problem, and they should take their efforts elsewhere.  Telling them that was
a wise thing for us to do.  PICS hasn't been very effective, but at least IETF
didn't get bogged down with working on it, and was able to spend its energies
on other, hopefully more useful, pursuits.

] Then there is the lawful interception ("eavesdropping") thing. After a 
] lot of discussion the IETF came up with a very solid position on this: 
] we don't want to put eavesdropping capabilities in our protocols as 
] this leads to weaker protocols. But governments are requiring now 
] network operators to make lawful interception possible in their 
] networks. Now one way to do this would be to simply put in fiber 
] splitters all over the place and more or less build a shadow network 
] that routes copies of all traffic to a place where the required subset 
] can be handed over to the government. A slightly cheaper solution would 
] be to have existing equipment copy the "interesting" traffic and only 
] forward the copies to the handover location. I fully agree that it 
] would be much better if this weren't necessary, because it's a big 
] hassle and it still costs a lot of money. But most of us are living in 
] democracies, and our administrations and parliaments have decided that 
] this is necessary. 

IETF's job is to do what makes sense for the Internet and its users, not to
provide mechanisms that governments demand -  especially not when they are
not based in technical sanity, and not when they conflict with the interests 
of Internet users.  These days it is clear that the demands of governments,
even so-called democratic governments, are often in opposition to the
interests of their citizens.   IETF should not assume that government demands
are legitimate, and we should not try to decide which government demands are
legitimate and which aren't.  We should do what we think is best for the
Internet.

] I would argue that the IETF is _the_ place to work this out, because:
] 
] - the IETF has vast experience with IP in general
] - and IP security in particular
] - (nearly?) all IP vendors participate in the IETF
] - the IETF process is open and transparent
] - the IETF standards are available to anyone anywhere without limitation

Ah yes, and just ignore the technical infeasibility, ignore governments'
abuses of existing eavesdropping measures, and ignore the interests of the
Internet community.  Just give the governments what they need to monitor and
control people and pretend that everything will be okay.

There is no civil way to adequately respond to this.  But I will do everything
in my power to keep IETF from being subverted to these ends.
 
] If you want to see what can happen if a non-IETF entity does this, go 
] to http://www.opentap.org/documents.php3 and have a look at version 
] 0.1.2 of the TIIT specs. (Version 1.0.0 was created after several 
] vendors had tried to implement 0.1.2.)

Feel free to help them if you want to.  Just do it elsewhere.

] > Yes, some people will get frustrated with this.  So be it.  IETF 
] > cannot do its job properly without disappointing people.  Unless IETF says
] > "no" to  bad ideas, there is no reason for IETF to exist.  IETF is useless
] > unless  it's endorsement is a reasonably reliable indication of quality.  
] > Currently, IETF does not say "no" often enough - and that also has harmed
] > its  reputation.
] This depends on what the IETF wants to be. Does it want to be the 
] guardian of the internet protocols? Does it _only_ want to be this? It 
] seems to me that a very important function of the IETF is to get 
] vendors together to work out ideas. Now the IETF can pre-judge ideas 
] and only allow the "good" ones (or rather, it could if there were 48 
] hours in the day) but I don't think this is a good idea.

Of course, you haven't tried to manage IETF's meager resources.  You have no
idea how thinly spread we are.

] Alternatively, the IETF can go on the way it's doing now and not before 
] long vendors will find other venues to get together for this kind of 
] stuff.

It's been happening for many years.  Sometimes those efforts succeed, often
they fail for lack of backing or failure to anticipate some need.  IETF cannot
take on everything anyway.  We might as well try to do what good we can,
within our areas of interest and expertise.  But in order for IETF to
accomplish anything useful it must be selective in choosing where to invest
its energy.

] 
] > ] Like _anyone_ can predict what is going to be good for the internet
] > ] anyway. Large vendors are reasonable indicators of what is wanted in
] > ] the internet and what's going to happen in the internet, though.
] > I disagree with that also.  Large vendors do not represent their 
] > customers' interests, and they never have.  Quite often the interests of
] > large  vendors are diametrically opposite of their customers'.  Large
] > vendors want to maximize profit, customers want to maximize value.  Large 
] > vendors  want to lock in their customers, customers want flexibility. 
] > etc.  Which is part of why IETF rules stipulate that participants must 
] > act in  the best interests of the Internet as a whole.

] That's all very nice but reality is that the IETF writes protocols, and 
] vendors implement a subset of the body of the IETF's protocols and then 
] add some of their own. Customers then use a subset of what vendors 
] implemented. This makes the IETF's influence over what happens on the 
] internet indirect by two layers. If vendors come to the IETF that means 
] they're at least open to _some_ criticism, so the IETF shouldn't turn 
] them away unless there is a fairly clear intention of abuse of the IETF 
] process.

Experience indicates that attempts to steer vendors away from bad ideas within
IETF often fail.  Sometimes they do work.  It's a judgement call.

But the bottom line is that IETF should decide where to concentrate its 
energies - and should not consider itself bound by either the interests
of large vendors or governments.
 
] > There's a lot of garbage in deployed products.
] 
] What's worse than a bad standard? A bad standard with non-interoperable 
] implementations. 

Stongly disagree. Sometimes lack of interoperability is a good thing,
if it limits the ability of a bad protocol to be deployed, or if it provides
incentives to replace a bad protocol. In the short term operations people pull
their hair out trying to make shortsighted ideas work in practice, and that's
unfortunate.  But IETF needs to be primarily focused  on medium- or long-term
concerns, not spend its energies trying to fix every  poorly-desinged vendor
protocol out there.

] Having people work inside the IETF and lending endorsement are two very 
] different things.

Yes they are.  But unfortunately when people do work in IETF they expect IETF
to endorse that work even when the work is a failure.

] As long as we're listing problems: the whole RFC status thing is lost 
] on pretty much everyone. Stop publishing informational and experimental 
] RFCs.

Another shortsighted idea.  

Keith