RE: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]

John C Klensin <john-ietf@jck.com> Sun, 22 September 2013 19:05 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8920D11E813D for <ietf@ietfa.amsl.com>; Sun, 22 Sep 2013 12:05:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.669
X-Spam-Level:
X-Spam-Status: No, score=-102.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQJ-A8e2lc6K for <ietf@ietfa.amsl.com>; Sun, 22 Sep 2013 12:05:20 -0700 (PDT)
Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) by ietfa.amsl.com (Postfix) with ESMTP id 730F821F9EAF for <ietf@ietf.org>; Sun, 22 Sep 2013 12:05:14 -0700 (PDT)
Received: from localhost ([::1]) by bsa2.jck.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1VNoxl-000MoN-4C; Sun, 22 Sep 2013 15:04:57 -0400
X-Vipre-Scanned: 0358B590002C310358B6DD-TDI
Date: Sun, 22 Sep 2013 15:04:56 -0400
From: John C Klensin <john-ietf@jck.com>
To: Christian Huitema <huitema@microsoft.com>, Noel Chiappa <jnc@mercury.lcs.mit.edu>
Subject: RE: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
Message-ID: <C5BC1EBD797295224EB710B2@[192.168.1.128]>
In-Reply-To: <C91E67751B1EFF41B857DE2FE1F68ABA153DCB97@tk5ex14mbxc272.redmond.corp.microsoft.com>
References: <20130922110232.A21F018C140@mercury.lcs.mit.edu> <77216407B4EA84D7919E0E22@[192.168.1.128]> <C91E67751B1EFF41B857DE2FE1F68ABA153DCB97@tk5ex14mbxc272.redmond.corp.microsoft.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 22 Sep 2013 19:05:27 -0000

--On Sunday, 22 September, 2013 17:37 +0000 Christian Huitema
<huitema@microsoft.com> wrote:

>...
> It is very true that innovation can only be sustained with a
> revenue stream. But we could argue that several services have
> now become pretty much standardized, with very little
> additional innovation going on. Those services are prime
> candidates for an open and distributed implementation. I mean,
> could a WG design a service that provides a stream of personal
> updates and a store of pictures and is only accessible to my
> friends? And could providers make some business by selling
> personal servers, or maybe personal virtual servers? Maybe I
> am a dreamer, but hey, nothing ever happens if you don't dream
> of it!

I agree completely.  However, one could equally well say that
operations can only be sustained with a revenue stream and trust
models among parties that don't already have first-hand
relationships can get a tad complicated.  Setting up a
distributed email environment that supports secure communication
among a small circle of friends (especially
technically-competent ones) is pretty easy, even easier than the
service you posit above.  Things become difficult and start to
encourage centralized behavior when, e.g., (i) the community
allow basic Internet service providers to either prohibit
running "servers" or make it unreasonably expensive, (ii) one
wants the communications to be persistent enough that storage,
backup, and operations becomes a big deal, and/or (iii) one
wants on-net or in-band ways to introduce new parties to the
group when there are Bad Guys out there (which more or less
reinvents the PGP problem).  

Architecturally, one can make a case that the Internet is much
better designed for peer to peer arrangements than for client to
Big Centrally-Controlled Server ones, even though trends in
recent years run in the latter direction (and I still have
trouble telling the fundamental structural differences between a
centralized operation with extensive "web services" and users on
dumb machines on the one hand and the central computer services
operations of my youth on the other).

So, a good idea and one that should be, IMO, pursued.  But there
are a lot of interesting and complex non-technical barriers.

best,
   john