The IETF's problems

[Iljitsch van Beijnum]

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.

> ] 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. When writing, they tell 
you that if someone comments on something in your story, you should 
always take this seriously. The comment itself is usually not something 
you can immediately use, as most people aren't good writers so they 
don't know how to solve writing problems. But most people are decent 
readers so when they feel compelled to comment you can be pretty sure 
there is a problem. 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.

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

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

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. This takes care of the "if", "when", "why" and "who 
pays for it" so the only remaining question is the "how".

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

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

> 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. Let people 
work on their stuff within the IETF. This allows new ideas to seep into 
the IETF as well as long-time IETF principles to seep into these new 
protocols. Then, when the new protocols are as good as they're going to 
get, the IETF leadership can have some of the resident experts look the 
whole thing over and decide to lend its approval to the protocol or 
not. This way, the IETF doesn't need a crystal ball to see what's going 
to happen to a protocol in the future and even when a protocol isn't 
approved it has still benefited from the IETF's input. Last but not 
least, by also applying this methodology to "homegrown" protocols the 
IETF gets to raise the quality level of the protocols that are approved 
while at the same time being able to take on projects where success 
isn't automatically guaranteed.

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.

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

> ] They're implementing the stuff most boxes connected to the net will 
> be
> ] running a couple of years from now.

> The stuff may be in those boxes, and people may even try to use it.  
> But that
> doesn't mean it's deserving of standardization or endorsement.  
> There's a lot
> of garbage in deployed products.

What's worse than a bad standard? A bad standard with non-interoperable 
implementations. (Yes, operations work has its downsides.) Having 
people work inside the IETF and lending endorsement are two very 
different things.

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