Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF)

Kyle Rose <krose@krose.org> Fri, 29 July 2016 13:08 UTC

Return-Path: <krose@krose.org>
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 7490912D5A3 for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 06:08:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 2bALdBh1feKf for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 06:08:06 -0700 (PDT)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 226A112D0F9 for <spud@ietf.org>; Fri, 29 Jul 2016 06:08:06 -0700 (PDT)
Received: by mail-qt0-x229.google.com with SMTP id u25so65817005qtb.1 for <spud@ietf.org>; Fri, 29 Jul 2016 06:08:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3PizhZfjZX00mQLgq12Qzw+N1KYWkaX66c33WLNATnk=; b=dQSW1FwxLJiYJBfAYaR096anKPPbObb1XVTqKWReJ+ikw7I5ic81yX+0nMeR4621R4 HWWEGBC/KhqHTp1SmWSSX8JO6csTt8aD7UTzWrNZmwksy05tLDHVBuSK3/KtkAKn40mG jb0p58yxxZK4XJnYsnLpPsgzXmIyq19nvu4oQ=
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=3PizhZfjZX00mQLgq12Qzw+N1KYWkaX66c33WLNATnk=; b=aMfrHb4V1Dq87qlBxkz+g+6wX00ldEMhjQcodEqD142HPpsKDXx5/Ywwp2GTj7eHdX 3+lnsdx3gl0xNVGjctzwHYERb8rLwjEh2ed+z0fVbqLYtbXGZR3epV8jI6k5LIavUYLt vX/1CGbLKaJXYh3/aSMpxJOhXuFTmDcU5Y3pyIO15VMzQbBbWAGrQO8jtAPqGeq828G7 993/Ozy0tToMvSU7T9ng7wcJprni1hU+KiE7kmF+m8x9+2abYL8OGS49D2CMAv8pHTO3 MgmKim5nRFBOjx0WvJ6gdHvKd2ITqIT8Jd0F039yiHYSgpAOpLc5katvb8PPhk3Fczj8 649g==
X-Gm-Message-State: AEkoouuGsWmsnybUHduENOHSB6D/l4BdWXpeEBoZsAl2//y9bcusx9hkOR3JZu/PvTUOcK3QB8+r2ZAoFilnfg==
X-Received: by 10.237.51.162 with SMTP id v31mr65361118qtd.1.1469797685151; Fri, 29 Jul 2016 06:08:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.94.70 with HTTP; Fri, 29 Jul 2016 06:08:04 -0700 (PDT)
X-Originating-IP: [2001:470:1f07:121:55a1:ece1:303c:874b]
In-Reply-To: <c22a9729-12c9-a4ee-a0f8-eb7548b3d553@cisco.com>
References: <CAKC-DJjVF_mQb49BJmHNpt-VkJSX6JHXH8hTbYMm2bEYg3rgwA@mail.gmail.com> <CALx6S3636tzxpqjr5b+31sU5vg+8UyekhhR=R-3SUYeQhYvjug@mail.gmail.com> <E8355113905631478EFF04F5AA706E98310462EA@wtl-exchp-2.sandvine.com> <CALx6S36jXoWZxrbictFD2z3=x8XTU6OAGLw-CJjkxrMwpaouYQ@mail.gmail.com> <073728f6-f532-297f-0289-f6e9142bec62@cisco.com> <CAJU8_nV7jeFmv+4UK8X1KyTL9Xo7bWi3he6vUZnr=Jx-_XFV-g@mail.gmail.com> <c22a9729-12c9-a4ee-a0f8-eb7548b3d553@cisco.com>
From: Kyle Rose <krose@krose.org>
Date: Fri, 29 Jul 2016 09:08:04 -0400
Message-ID: <CAJU8_nXEsw-fLMBH=efsrKyyLw1Mja-niFOgp_1XT=Ne6MB_UA@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Content-Type: multipart/alternative; boundary="94eb2c124a32ea80070538c5f0ba"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/984a-E_zOf84Uki2YkE-flGDgyk>
Cc: Tom Herbert <tom@herbertland.com>, spud <spud@ietf.org>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Dave Dolson <ddolson@sandvine.com>, Erik Nygren <erik+ietf@nygren.org>
Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF)
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, 29 Jul 2016 13:08:07 -0000

On Fri, Jul 29, 2016 at 9:01 AM, Eliot Lear <lear@cisco.com> wrote:

> Kyle,
> On 7/29/16 2:39 PM, Kyle Rose wrote:
>
>
> No one is going to break the sockets API anytime soon, but having to
> develop a new API for modern protocols would be a nice problem to have.
> First, though, we need to figure out how to route those protocols through
> the boxes that right now assume the entire internet runs over a snapshot of
> TCP from 20 years ago.
>
>
> We now have platforms that lose backward compatibility in as little as a
> year.  And so if a transport interface is being rev'd, a developer may be
> left to only guess at which point it will be stable.  In as much as the
> semantics are changing, that's a problem.
>

Are you referring to QUIC? What you highlight is precisely why Google did
*not* take it to IETF too quickly: because they wanted to retain the
ability to revise it quickly during a period of intense experimentation. No
one here doubts that standardization necessarily brings stability in terms
of backward compatibility to the API and wire protocol, but I imagine one
of the things we'll be focusing on in the QUIC WG is how to enable future
evolution within the constraint of interoperability with older versions.

Kyle