The IETF's problems

[Iljitsch van Beijnum]

On zondag, jul 20, 2003, at 17:16 Europe/Amsterdam, Keith Moore wrote:

> since most of this is not in scope for problem-statement - either it
> is solution space or something else entirely - I'll make my public
> reply brief, and reply privately in more detail.

Ok.

> - your proposed solutions for managing increased workload will not 
> scale,
> nor will they ensure technical soundness.

You are right that creating a structured way for the membership at 
large to review doesn't magically solve everything. But I'm pretty sure 
it will at least help. More when I've subscribed to the solutions list.

> - you are being unrealistic in expecting IETF to take on every bit of
> work for which there is interest, even if IETF doesn't give them a 
> working
> group

Ok, I guess I am. However, the current situation is very problematic, 
as the filter that must let in useful new work and keep out 
not-so-useful new work doesn't really do its job. I would even like to 
go so far as it keeps out new people to a very large degree while those 
in the inner circle can pretty much put anything they want on the 
agenda.

> - it is not in the interests of the Internet, nor in the interest of 
> IETF,
> for IETF to support the efforts of governments to use the Internet for
> surveillance.  no matter how well-intended, IETF will not be able to 
> limit
> the efforts of governments who wish to use this capability 
> inappropriately.
> IETF work in this area can at best be a waste of its energy, and at 
> worst
> lend support to corrupt governments.

How stubborn can one person be?

1. The law says operators must be capable of X.
2. In order to do X, operators need capability Y from their equipment.
3. A vendor comes to the IETF and says: let's standardize a protocol 
for doing Y.

Now how is frustrating 3. going to keep X from happening???

In fact, failing to create a way to limit interception to only that 
which falls withing the scope of the warrant almost guarantees 
governments will end up with more intercepted data than they asked for. 
How can this be a good thing?

> and for the one topic relevant to problem-statement:

> - I agree that with so many RFCs the distinction between the various
> kinds of status is unclear.  however experimental and informational
> RFCs are useful as supplemental material to standards documents,
> and for other purposes, so I do not agree with your proposed solution.

I think we've been miscommunicating here. I didn't mean these shouldn't 
be published anymore, just that they shouldn't share a namespace with 
standards documents. I completely agree that there is lots of useful 
supplemental material. However, not nearly enough of it is published in 
a structured way. For instance, I can understand why someone would 
think the deletion of drafts is a good idea, but in practice this 
really doesn't help with anything.