[Spud] questions on the BoF outcome

"Fossati, Thomas (Nokia - GB)" <thomas.fossati@nokia.com> Fri, 22 July 2016 10:25 UTC

Return-Path: <thomas.fossati@nokia.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F0C3912DC89 for <spud@ietfa.amsl.com>; Fri, 22 Jul 2016 03:25:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kTIjoBhF_mfw for <spud@ietfa.amsl.com>; Fri, 22 Jul 2016 03:25:52 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDFB12DFC3 for <spud@ietf.org>; Fri, 22 Jul 2016 03:25:52 -0700 (PDT)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown []) by Websense Email Security Gateway with ESMTPS id EED1E6EF50900 for <spud@ietf.org>; Fri, 22 Jul 2016 10:25:47 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com []) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u6MAPoJO002792 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <spud@ietf.org>; Fri, 22 Jul 2016 10:25:50 GMT
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com []) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u6MAPoaJ011804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <spud@ietf.org>; Fri, 22 Jul 2016 12:25:50 +0200
Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([]) with mapi id 14.03.0195.001; Fri, 22 Jul 2016 12:25:50 +0200
From: "Fossati, Thomas (Nokia - GB)" <thomas.fossati@nokia.com>
To: "spud@ietf.org" <spud@ietf.org>
Thread-Topic: questions on the BoF outcome
Thread-Index: AQHR5ANq+tZUgMMtYEuhq8vSOXYEcw==
Date: Fri, 22 Jul 2016 10:25:49 +0000
Message-ID: <D3B7A676.6E71A%thomas.fossati@alcatel-lucent.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <78727A36A0A05D408CBC4F775A89F4ED@exchange.lucent.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/oUeQk5JJSlH7cyz68TF9Iehlw7Q>
Subject: [Spud] questions on the BoF outcome
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 22 Jul 2016 10:25:56 -0000


Unfortunately I could not attend the PLUS BoF.  So, I've just gone through
the minutes [1] (thanks a lot, scribes) and got the feeling that this work
is pushed back due to the perception that it'd weaken users' privacy?

I hear these arguments:
- "potential to compel clients to send metadata or packets will dropped"

But that could have happened already if the network wanted to (just drop
any TCP payload that starts with 0x16 and allow only clear-text traffic!).
 Access networks that you pay for do not have that incentive though, so
I'm very skeptical this could now happen *because of* PLUS.

- "possibility for abuse"

Well, that depends on the metadata that *users* decide to leak (which is a
separate discussion on the vocabulary), but in general Brian's framework
looks pretty well designed to bias control towards the endpoints which can
act as circuit-breakers at any point in time.

- "giving more power to the network";

This is actually true, but in a good way: the network will have power to
send useful information to the endpoints -- if it's asked to -- while
being empowered by the signalling coming from the endpoints (e.g., for
DDoS prevention).

So, sorry but this looks a lot like FUD to me.

Is the working group not formed on these grounds?  Or have more
substantial weaknesses been highlighted during the discussion that have
not been captured in the minutes?

Cheers, thanks,

[1] http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-plus