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

Kyle Rose <> Fri, 29 July 2016 13:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7490912D5A3 for <>; Fri, 29 Jul 2016 06:08:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2bALdBh1feKf for <>; Fri, 29 Jul 2016 06:08:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 226A112D0F9 for <>; Fri, 29 Jul 2016 06:08:06 -0700 (PDT)
Received: by with SMTP id u25so65817005qtb.1 for <>; Fri, 29 Jul 2016 06:08:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id v31mr65361118qtd.1.1469797685151; Fri, 29 Jul 2016 06:08:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 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: <>
References: <> <> <> <> <> <> <>
From: Kyle Rose <>
Date: Fri, 29 Jul 2016 09:08:04 -0400
Message-ID: <>
To: Eliot Lear <>
Content-Type: multipart/alternative; boundary=94eb2c124a32ea80070538c5f0ba
Archived-At: <>
Cc: Tom Herbert <>, spud <>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <>, Dave Dolson <>, Erik Nygren <>
Subject: Re: [Spud] Bare-minimum PLUS (was Re: Thoughts on the privacy concerns expressed at the BoF)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 29 Jul 2016 13:08:07 -0000

On Fri, Jul 29, 2016 at 9:01 AM, Eliot Lear <> 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.