Re: [Spud] questions on the BoF outcome

Ian Swett <ianswett@google.com> Fri, 22 July 2016 14:49 UTC

Return-Path: <ianswett@google.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC0712D5BD for <spud@ietfa.amsl.com>; Fri, 22 Jul 2016 07:49:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.986
X-Spam-Level:
X-Spam-Status: No, score=-3.986 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 5_vwnmyhia6n for <spud@ietfa.amsl.com>; Fri, 22 Jul 2016 07:49:09 -0700 (PDT)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53C812D1AC for <spud@ietf.org>; Fri, 22 Jul 2016 07:49:08 -0700 (PDT)
Received: by mail-io0-x231.google.com with SMTP id 38so107222225iol.0 for <spud@ietf.org>; Fri, 22 Jul 2016 07:49:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8BRn1IQs3kuFoTEityUCMwTVeSa5/fL3DsanjO11V2o=; b=PM6ofBZxBBrj77tUf+jHZNAUXzpZF49eL/DthVW8GepDw+Q6/YvzMV+CP+zsDAwisj Kqa4lpcGJYNwBECZaT47Cllh0nc6HYyRoe/Umktz9059/i9OBrp/y82PGzBb25Ev3L6u kFXLGxLX7Xt/85/hOBkSI4v88pUx+9gfF0wNgy/9V766XEz7ZDPUdtthC54kRpTebXoQ 9cJSC1sEUrjFARv7wY6ZLQS0WcWM5cCSd/sGBfwHppu2/0Kd+Q+/Bp3cz+pz3iEMBemx kFJM+6XW1BGBNHFKCU7NodBge+6jNBhiJq2VvHhHSl6DUGO2Wgd/5TeVFxZmT99Vkmcm WNOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8BRn1IQs3kuFoTEityUCMwTVeSa5/fL3DsanjO11V2o=; b=Xbp4KKLUowRSwT/YbDKkhDmTkhuR4v2sprTLSYcdDB9Vz8TiVLSU47n2aat8IghVwD eqa5ItwxltrMj8B2lLPCfoDaE0Kq1ObaBtbXjUwllNyKO9pchqawRIVVZFUE/RNqbmmT hZeL23iK0GsvV4GCFfvATC/wppik+6dVZHi6OmcSRxaNLmW7HOHxEtHcm/OAGmO56PX+ T+ORMut0UzdmbUu1IJaOV0gCSuHk9txMTxcKN4Ia0p9qxf98tDelqEHf0ObRZOKaJqzt r7pqdS/5g/XVuYUTn/ZkyvkLApOXQMK0ITVvFjutLgVTFLbePOxeiwEfO5E7f8BC8yZM mbFQ==
X-Gm-Message-State: AEkooutc1sPJEJ+awVCijQNqLKfJQ9uRcg7M7veI0WPL01hFCAg05Vw5qC3Og2rNmihrKF6D1VO2TYjx28/SpomJ
X-Received: by 10.107.9.42 with SMTP id j42mr4891580ioi.33.1469198948045; Fri, 22 Jul 2016 07:49:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.64.15.73 with HTTP; Fri, 22 Jul 2016 07:48:47 -0700 (PDT)
In-Reply-To: <EA4C43BE752A194597B002779DF69BAE241328D0@ESESSMB303.ericsson.se>
References: <D3B7A676.6E71A%thomas.fossati@alcatel-lucent.com> <EA4C43BE752A194597B002779DF69BAE241328D0@ESESSMB303.ericsson.se>
From: Ian Swett <ianswett@google.com>
Date: Fri, 22 Jul 2016 10:48:47 -0400
Message-ID: <CAKcm_gMn3ubbSs7t2Vk6FkSUqFDn4x_Lm6c5gfM_-Nwx8Vy1-Q@mail.gmail.com>
To: Szilveszter Nadas <Szilveszter.Nadas@ericsson.com>
Content-Type: multipart/alternative; boundary=001a113df6ac67990605383a898d
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/Z7lc_VmUN7X-5RLVxPiU6EAico0>
Cc: "Fossati, Thomas \(Nokia - GB\)" <thomas.fossati@nokia.com>, "spud@ietf.org" <spud@ietf.org>
Subject: Re: [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 14:49:11 -0000

I hummed no largely because I felt I didn't clearly understand the work of
the group, and hence couldn't evaluate whether it was possible and
desirable.

I personally would have preferred a clearly scoped set of initial use
cases, with other use cases of potential future interest requiring a
re-charter.

I believe there are a lot of people interested in something along these
lines, so my no hum was not an expression they should stop trying to move
forward with a WG.  I also want to continue having the conversation about
what the path needs at the IETF, because it comes up fairly often, but I
feel there's currently no coherent forum for the conversation.

It would be great to see some amount of running code as well, with some
clearly improved metrics for that particular use case.  I would hope small
scale experiments would inform the WG on what topics may warrant a
re-charter.

On Fri, Jul 22, 2016 at 6:29 AM, Szilveszter Nadas <
Szilveszter.Nadas@ericsson.com> wrote:

> Hi,
>
> Some other argument was e.g. overhead. There was a significant amount of
> "NO" hums for the first question, the rest of the questions was not even
> asked.
>
> It is also not clear to me, is there still hope, or is it hat eating time?
> :)
>
> Cheers,
> Sz.
>
> > -----Original Message-----
> > From: Spud [mailto:spud-bounces@ietf.org] On Behalf Of Fossati, Thomas
> > (Nokia - GB)
> > Sent: Friday, July 22, 2016 12:26
> > To: spud@ietf.org
> > Subject: [Spud] questions on the BoF outcome
> >
> > Hi,
> >
> > 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,
> > t
> >
> > [1] http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-plus
> >
> > _______________________________________________
> > Spud mailing list
> > Spud@ietf.org
> > https://www.ietf.org/mailman/listinfo/spud
>
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud
>