Re: [Spud] SPUD Scope?

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Mon, 08 June 2015 07:57 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8880A1B2D49 for <spud@ietfa.amsl.com>; Mon, 8 Jun 2015 00:57:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.21
X-Spam-Level:
X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8JevL2el9qi for <spud@ietfa.amsl.com>; Mon, 8 Jun 2015 00:57:31 -0700 (PDT)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 917581B2D4B for <spud@ietf.org>; Mon, 8 Jun 2015 00:57:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 73946D9319; Mon, 8 Jun 2015 09:57:29 +0200 (MEST)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id x1caYMoPI2aq; Mon, 8 Jun 2015 09:57:29 +0200 (MEST)
Received: from [192.168.178.33] (x5f71602c.dyn.telefonica.de [95.113.96.44]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 0790ED9303; Mon, 8 Jun 2015 09:57:28 +0200 (MEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: =?utf-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
In-Reply-To: <87vbeztlp8.fsf@alice.fifthhorseman.net>
Date: Mon, 8 Jun 2015 09:57:28 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <47D686FE-C037-42A5-A1F2-7A07318451D0@tik.ee.ethz.ch>
References: <EA4C43BE752A194597B002779DF69BAE23D47A3E@ESESSMB303.ericsson.se> <87h9qn1dkr.fsf@alice.fifthhorseman.net> <DM2PR0301MB0655E175AD817C6D896F7E7DA8B30@DM2PR0301MB0655.namprd03.prod.outlook.com> <EA4C43BE752A194597B002779DF69BAE23D48602@ESESSMB303.ericsson.se> <87oaktvjhi.fsf@alice.fifthhorseman.net> <1FA5B1A9-6011-4F39-8503-ACAAB5B649A8@netlab.uky.edu> <87vbeztlp8.fsf@alice.fifthhorseman.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/EQkjln5pspS2FSm59xwGxYUF4zg>
Cc: Ken Calvert <calvert@netlab.uky.edu>, "spud@ietf.org" <spud@ietf.org>
Subject: Re: [Spud] SPUD Scope?
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jun 2015 07:57:33 -0000

Hi dkg,

only one second/last point…

> Am 07.06.2015 um 20:30 schrieb Daniel Kahn Gillmor <dkg@fifthhorseman.net>et>:
> 
> On Sat 2015-06-06 13:44:33 -0400, Ken Calvert wrote:
>> Yes, the path is fraught with challenges; I don't disagree with most
>> of your points.  On the other hand, call me an optimist, but I believe
>> such a mechanism could not only help break the "ossification" logjam,
>> but perhaps eventually shift the balance of power back toward the end
>> users by giving them more choices w.r.t. network services.
> 
> how would this mechanism give the users more choice w.r.t. network
> services?  It looks lke a way to facilitate additional metadata leakage
> *to* network providers.  are you suggesting that some network providers
> would require more metadata than others, and users collectively ("the
> marketplace") could collectively select network providers on the basis
> of their metadata collection policies?
> 
> If this is the suggestion, i think it vastly overestimates the average
> user's (a) knowledge of the underlying mechanism, (b) ability to assess
> their own risk from particular metadata leakage to a given provider, and
> (c) time available to deal with the choicepoints presented (by each
> network connection?) by this scenario.
> 
It’s not the different network providers that need different information but you may want to provide different information about different ‚kind‘ of services so that the provider might be able to treat your traffic more appropriately (which effectively can provide you a better service as well as save network resources). However, a user might choose to not reveal this information and only get the default treatment which might or might not be good enough (whatever ‚good‘ means here). And here there might actually be differences between the providers (and the contract that the user made with its provider).

Mirja