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 12:39 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 7671712D638 for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 05:39:34 -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 wqyGSQQ7O9in for <spud@ietfa.amsl.com>; Fri, 29 Jul 2016 05:39:32 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::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 CABC912D589 for <spud@ietf.org>; Fri, 29 Jul 2016 05:39:31 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id o67so89246381qke.1 for <spud@ietf.org>; Fri, 29 Jul 2016 05:39:31 -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=NA7VWOqs2BMehd0+ok+xDIKJ8Sf/ULRf5ji7uZKI8LI=; b=bkHBkjRUS40cCkP8Z70sEql3z0AQeENCEJihZErDvDwByVOr9Rmikgjc65muMOe6Bs xaEGdC0m1y48fbVi5+l52BFp1BtX3InGuYdfiH7VEzYIplwePw3nr1lug2GcJPBZ3UTT pKurjzokOR4GZSIgyYS8gC+FGmASG/IsCQdNg=
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=NA7VWOqs2BMehd0+ok+xDIKJ8Sf/ULRf5ji7uZKI8LI=; b=TvTWdUUBVeiYoWSVq3hm2utMONxALNa2XPLg6QbgJnTImUjSae0dE1WATm7BfpDzKL zc5AazzPnXlDOCCjHU/cNAoe1LRhqvFDKAShhkXqTB8YqXB8UZWcQkFI/LYxFXmM9Id+ bo9nUnPdSq1x5+bUh/dnLy0LyQOssG87k2mTi9iq1Npl8Z7F8R+qtobqohvSDo+xbuWx NjXodSHjfbEvlJiEf68gkJND7CwI2zNid74nNxdoL0Iu5W6T1rPeTwL+m3YL/zqgakHt c7aNdGuCIaQqLIxaJJ/Aw1AGxVfc646p9+p08xSd4QpQy5lgNWG2BIqziMlQg1TNpQqx cRJw==
X-Gm-Message-State: AEkoousBoCOeoQX/cbpMUujn9aJmACFnz22zfJUfHghG4gm3kjwrPs/NT2dbd9l+gDfn3V6yjgLS16qIJTB6jA==
X-Received: by 10.55.98.205 with SMTP id w196mr50156374qkb.65.1469795970934; Fri, 29 Jul 2016 05:39:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.94.70 with HTTP; Fri, 29 Jul 2016 05:39:30 -0700 (PDT)
X-Originating-IP: [2001:470:1f07:121:55a1:ece1:303c:874b]
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: Kyle Rose <krose@krose.org>
Date: Fri, 29 Jul 2016 08:39:30 -0400
Message-ID: <CAJU8_nV7jeFmv+4UK8X1KyTL9Xo7bWi3he6vUZnr=Jx-_XFV-g@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Content-Type: multipart/alternative; boundary=94eb2c056648bdb0820538c58a06
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/tYhSHAy2pSRynAnLIQdJMTrbOSw>
Cc: Tom Herbert <tom@herbertland.com>, spud <spud@ietf.org>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <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 12:39:34 -0000

On Fri, Jul 29, 2016 at 8: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.
>

I think this conflates two issues. I think of "ossification" as unintended
structure that precludes development within the protocol stack, something I
think is broadly accepted as a problem by people who are trying to improve
the experience of users. What you are talking about here seems to be
stability of the API for a specific protocol. Frankly, if we apply
"ossification" to that then the term becomes overly broad and therefore
meaningless. I don't think anyone is suggesting that all APIs should be
randomly perturbed over time just to see what happens.

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.

Kyle