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

Tom Herbert <tom@herbertland.com> Fri, 29 July 2016 15:58 UTC

Return-Path: <tom@herbertland.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 0486A12B068 for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 08:58:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 DeyM_dB-S6Ae for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 08:58:25 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 7661512B042 for <spud@ietf.org>; Fri, 29 Jul 2016 08:58:24 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id f6so111839454ith.0 for <spud@ietf.org>; Fri, 29 Jul 2016 08:58:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l6CZwz1NyGW1wu7Rd3ejz0+XHioTC++Fd+ZtwHPxRmY=; b=ioSTMAJPqbumcaUaSEf4za32yHPvOXuDqZGUjNx+T2MOHtTKHv1FaCI5LZkmbjqVgs RB0bvGiAtBtov7ghtQ0AsX/7BQggYsKbtR+xfv1l5Kjii3cCnFESvuObcDC2f6Megx1a N7aUPnHfuitfNxqsVCpXH892TL71IDRa9MUzlHLpmafOPkCFm0k2tthGjQxxedtqdvnP zqGgF90GP2xxn9Kr2/muXHig5ssHs4xrdCIcgSVQRXxpq1Q9saHrsh03eH9+a0Sc6RPj zRMMEAh0AWkVt4/UdJuUBmSRnr51ll6V19TZYyOPa76Zn7UigNbX33TZaHdYtnKOE8vy x4QA==
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=l6CZwz1NyGW1wu7Rd3ejz0+XHioTC++Fd+ZtwHPxRmY=; b=C0lB3rM2UUnzGxVQK6azbLXZiqErVy246OV0WxhJ32Svk5coVIV/EK2Me18PlRFBNl 6Q/2Z6av0GuxZ2VUpE8P/ED1smxxXd16elf85LVAJYlzHKorRPgpqg+mhak7VshOh5dx 9TA0VIDatoOTCj1Y/M6zSP+Jqb+Vcpu4jcBd6aePi0lzP6K/HO8BbjeWY2TWfAFUfZt6 cS2JVKBmytpQUW6dLheexsJfO2QEPA4S4Fsj/mnsYNQoHGlKm+BHE/SjjDO//q0kyacI ySKu2rzcp8nLQlOYD+NIAG8OAQZ6K93P24pwCnt8vKbTB9jf1q0eWFdD8IDYO2f7BiO+ /o+g==
X-Gm-Message-State: AEkoousdTxyw0lFnojlM1aUJaVzhBT0dE10hLVvveVYAqHdyzybS1F+JOwm1a5WlTt1kLsg/hi9yS8RPBZ6VXw==
X-Received: by 10.36.14.193 with SMTP id 184mr47436358ite.91.1469807903729; Fri, 29 Jul 2016 08:58:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.21.130 with HTTP; Fri, 29 Jul 2016 08:58:23 -0700 (PDT)
In-Reply-To: <073728f6-f532-297f-0289-f6e9142bec62@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>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 29 Jul 2016 08:58:23 -0700
Message-ID: <CALx6S37nL6_=n9Le7b4WtJgHVPwN6wP=GrJhZ2hz8se3+Efwiw@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/1PP_QK83-9VL_Kgv1pf0zKPqmQ8>
Cc: Erik Nygren <erik+ietf@nygren.org>, Kyle Rose <krose@krose.org>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Dave Dolson <ddolson@sandvine.com>, spud <spud@ietf.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 15:58:26 -0000

On Fri, Jul 29, 2016 at 5:18 AM, Eliot Lear <lear@cisco.com> wrote:
> Hi Tom,
>
> Something that did not get brought up at the BOF is nagging at me...
>
>
> On 7/28/16 8:17 PM, Tom Herbert wrote:
>> The abstraction is only useful up to the point that networks preserve
>> the model. If the network breaks the model in ad hoc ways that forces
>> the application to try to compensate with more ad hoc mechanisms or
>> just stop innovating altogether as we see happened with protocol
>> ossification.
>
> You write that as if it's a bad thing ;-)
>
> Some amount of protocol ossification is a GOOD thing.  In particular,
> the calling interface for transports needs to be stable or source code
> will have no shelf life.  The fact that TCP's calling interface has been
> SO stable for SO long has meant that a large code base did not require
> substantial maintenance just to keep doing the same thing it was
> doing.   I see this as an exercise to determine what needs ossification
> and what does not, and there are extreme positions at both ends.
>
Note that I specifically referred to 'protocol' ossification not
'interface' ossification. In fact, the TCP sockets interface is
constantly being extended. For instance, in order to make TCP Fast
Open (TFO) work we needed to change the semantics of 'connect' call
and allow sendmsg on an unconnected socket.

Tom


> Eliot
>
>