The IETF's problems

[Iljitsch van Beijnum]

On zaterdag, jul 19, 2003, at 22:25 Europe/Amsterdam, Keith Moore wrote:

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

How can they be obvious?

I'll get into this a bit more on the "solutions" list but the way I see 
it is that the IETF should say: sure, we'll put up a mailinglist, we'll 
give you a slot in a room to talk about this during meetings and we'll 
accept drafts if IETF participants from at least X different 
organizations support this. When you're ready for this you get to 
propose the protocol to a working group that may or may not accept it 
as a work item. If the wg accepts it, at some point the IESG will have 
the work reviewed and it can be published as a draft standard. If not, 
then it may be published as experimental or informational.

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

That's why it doesn't make sense to evaluate each and every proposal or 
-00 draft. But if participants from at least three or so organizations 
work on something for 6 months or a year and they all feel the protocol 
has merit, I think it's reasonable to spend some time looking at this. 
As for resources: the IETF has thousands of participants. I'm sure at 
least a few hundred are prepared to review proposed protocols from time 
to time, especially if they know their opinion really counts because 
they're "official" reviewers rather than the current situation where 
everyone must decide for themselves if they want to review something 
and there is no way to know whether this input will be taken in 
consideration by the powers that be.

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

Obviously the IETF leadership should be capable of withstanding this 
type of pressure. And letting it simmer in a non-endorsed "ad hoc 
group" or whatever we want to call it probably gets rid of a fair share 
of bad proposals because those will very likely draw the attention of 
private participants with opinions on the matter without the need for 
formal action by the leadership.

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

If you can get something into a wg then you're well on your way to 
having it endorsed by "the IETF". So let people work on it outside a wg 
and then when there is plenty of opportunity to say "yea" or "nay". 
This forces people to work on the technical side of protocols first 
rather than getting something inside a wg.

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

Missing the point by a wide margin...

Operators must take certain actions because these are demanded by 
governments. (This isn't entirely unreasonable by the way: do we want 
the internet to be a place where people can break the law in ways they 
can't elsewhere?) So operators look to their vendors to implement 
certain functionality. Yes, this sucks, but it's going to happen 
anyway. But let's at least standardize the handover interfaces so 
operators / mediation implementers only have to spend money on 
implementing this once.

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

Nonsense. It's done today. But in proprietary ways that are more 
expensive than necessary.

> ignore governments' abuses of existing eavesdropping measures,

People sometimes pull the emergency break for no good reason. Rip them 
out then.

This is a non-technical issue that must be addressed through 
nont-technical means.

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

On the internet everyone is nice so we don't need law enforcement. Yeah 
right.

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

This is a balancing act. You don't want to give unlimited power to 
governments because power corrupts and it _will_ be abused at some 
point. On the other hand, you don't want to leave governments powerless 
because that leaves us with the law of the jungle. Obviously different 
people are going to favor different tradoffs, but I think one where 
people get to use strong crypto, but governments have the ability to 
monitor the encrypted traffic under certain circumstances is a fair way 
to do it. This makes casual intrusion of privacy by governments very 
hard, but when necessary, it's still possible to uncover networks and 
gather information that can likely be decrypted and used as evidence 
later if and when the keys are recovered using more traditional 
techniques (search warrant).

The IETF did the right thing twice before by creating protocols that 
allow strong encryption, and then refuse to add backdoors. Now it's 
time to do the right thing a third time by standardizing handover and 
provisioning protocols so operators can fullfil their obligations under 
the law in the most cost-effective and safest possible way.

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

:-)

The real question is: do YOU want your ISP to have this stuff in their 
network?

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

So let the participants earn their keep. Submit a draft? Review two 
others. With enough reviews for each protocol and for each reviewer, 
there shouldn't be much problems in determining which reviews have a 
high statistical likelihood of being "good".

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

The way things are going now is a road leading nowhere: just reading 
all the drafts that come out is a full time job. So either _really_ do 
this and limit what's being done under the umbrella of the IETF by an 
order of magnitude or so, or remove the pretense of any selection on 
the input side but focus on the output side after the useful (which may 
or may not equal "good") ideas have floated to the surface. I can 
imagine a system where the IESG has time to evaluate n proposals (where 
n can be increased by not trying to do the full technical review inside 
the IESG) per unit of time so it simply evaluates the n proposals with 
the most support from the IETF membership at large. (Where membership 
could be "showed up at the meeting" or something else.)

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

If the protocol isn't bad enough that it carries an inherent incentive 
for replacement, then maybe it's not so bad after all.

> In the short term operations people pull
> their hair out trying to make shortsighted ideas work in practice, and 
> that's
> unfortunate.

That's what we need, operations people with less hair...

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

Don't fix it. Give them a mailinglist and a meeting room and a 
whiteboard. They are big boys and girls so they can do this themselves. 
The good stuff will float to the surface.

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

I think there is rough consensus on what should be done in these cases.

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

Maybe. But with close to 3000 RFCs out there and nearly noone knowing 
which are jokes, which are curiosities, which are [the list goes on] 
and which are standards, there is a problem that needs to be addressed.