Subject: Re: [Raven] Re: (no subject)

From: Sampo A Syreeni <[email-masked]>
Date: Wed, 1 Dec 1999 14:39:23 +0200 (EET)

On Tue, 30 Nov 1999, Ed Stone wrote:

>A proper response to the question "Should we give the police department a 
>key to the front door?" would be "yes (and optionally with reasons)" or "no 
>(and optionally with reasons)". It would **not** be "The key we give them 
>could activate 10-pins,
[Snip]

Yet if it turned out the only key we could give was something that would
unconditionally open every single door there is, this would be very
relevant to the original decision on granting the key or not. However, if we
could guarantee that only some minimal number of doors (say, just the front
door) could be opened, then we could come up with a positive answer.
The same goes for chefren's (rather annoying) auditable taps chant -
if it turned out all the police need we they ask the key was really a camera
telling who went through, we could end up saying 'sorry, no key since you
have no need for it. have this camera instead'. Also a very valid reason to
say no in the first place.

The reasons and consequences of the decision have to be considered before a
consensus can be reached. (And no, I am not advocating turning this list
into a technical forum. All I'm saying is that should there be workable
alternatives to tapping, their existence could have some weight on the
decision.)

>Least persuasive, and even damaging to the frail point made, is the 
>assertion that the existence of a discussion list is indication that the 
>question posed was not to receive "yes/no" treatment. As if one's "yes" or 
>"no" would not have a "why" behind it that merited discussion!

Pointing out alternatives to tapping, the consequences of specific
approaches to tapping, their validity and sufficiency and the overall
possibility of achieving a tapping architecture without handing every and
all data moving on the Net to your friendly government are an essential part
of that discussion. Making policy decisions in the context of technology
always involves the technology itself.

>The first point seems to be "before we consider whether or not IETF should 
>develop or modify protocols to support wiretapping, let's have the IETF 
>develop or modify some protocols to support wiretapping!"

No. Definitely not. The point is, before we consider whether or not IETF
should devlop or modify protocols to support wiretapping, let's have the
IETF think through the obvious consequences and approaches and see whether
we of hand see any fairly workable ways to do that at all. I think such
workable ways do not exist and so we should just acknowledge that tapping is
not a viable addition to the IETF's protocol suite.

>The second point seems to be "if you are for or against having the IETF 
>develop or modify protocols to support wiretapping, keep your reasons to 
>yourself!"

The second point is, if we want to have a vote, let's have a vote. If we
want to make real decisions, we need to discuss the matter at hand. This
necessarily entails more than just saying 'yes' or 'no', and in the case of
protocols, also some specifics.

If the question on the table was, 'should the IETF make IP more friendly to
carrying the data not by wire but by camel back', wouldn't you think such
technical details as latency and HTTP performance would be relevant?

After this post, I'll shut up about the nature of the question before
us. This is getting beaten to death.

Sampo Syreeni <[email-masked]>, aka decoy, student/math/Helsinki university

_______________________________________________
raven mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/raven