答复: The ecosystem is moving

"Hejianfei (Jeffrey)" <jeffrey.he@huawei.com> Wed, 11 May 2016 15:06 UTC

Return-Path: <jeffrey.he@huawei.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 1C69412D0E3 for <ietf@ietfa.amsl.com>; Wed, 11 May 2016 08:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.217
X-Spam-Level:
X-Spam-Status: No, score=-5.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 mehYqeaWAkxT for <ietf@ietfa.amsl.com>; Wed, 11 May 2016 08:06:45 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70DB12DB25 for <ietf@ietf.org>; Wed, 11 May 2016 08:06:44 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJR51457; Wed, 11 May 2016 15:06:42 +0000 (GMT)
Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 11 May 2016 16:06:42 +0100
Received: from SZXEMA507-MBX.china.huawei.com ([169.254.5.93]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0235.001; Wed, 11 May 2016 23:06:35 +0800
From: "Hejianfei (Jeffrey)" <jeffrey.he@huawei.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>, "ietf@ietf.org" <ietf@ietf.org>
Subject: =?gb2312?B?tPC4tDogVGhlIGVjb3N5c3RlbSBpcyBtb3Zpbmc=?=
Thread-Topic: The ecosystem is moving
Thread-Index: AQHRq4Tepvl3I40Ovk2jc5j20Dt4UZ+zyy1A
Date: Wed, 11 May 2016 15:06:35 +0000
Message-ID: <AB07990D3CAE53419132AB701C45693C83A5C9A7@szxema507-mbx.china.huawei.com>
References: <20160511125553.GA19250@sources.org>
In-Reply-To: <20160511125553.GA19250@sources.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.46.71.64]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.57334A83.01FD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.93, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 9313b1634bc183cd7e82bdfa2e2a63eb
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/lxVCz6-buH0-alD_IP2EpnkL5Mo>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 11 May 2016 15:06:47 -0000

Hi Stephane,

Thank you for sharing this information. This happens to be a topic that I have been considering for quite a while.
I agree on most of the observations in this paper, e.g. "once you federate your protocol, it becomes very difficult to make changes. And right now, at the application level, things that stand still don't fare very well in a world where the ecosystem is moving."
But I am also searching if there is different way to do federation in application world. 
Most of current federations at application level target specific applications, so many "semantics" in those applications are exposed to the peering/federating protocols/interfaces. Some people call it a " beads-on-a-string " architecture. It "naturally" results in the issue "hard to change". 
I am thinking if a "layered" architecture could be applied to the application world. The key point may be to define a function set, concise and sufficient for service innovations. The servers inside the federation implement these functions and turn a stable layer. The main goal is that to deploy new services, only the client software at the two ends need to be upgraded. 
No doubt that it is very challenging since unlike the connectivity, the services above connectivity are so various, it is questionable if it is feasible to define a stable layer conveying future service innovations. But I have an initial feeling that such a function set could probably be defined based on experience from file and database systems. But this idea is still at quite early stage...

Jeffrey 
  
-----邮件原件-----
发件人: ietf [mailto:ietf-bounces@ietf.org] 代表 Stephane Bortzmeyer
发送时间: 2016年5月11日 20:56
收件人: ietf@ietf.org
主题: The ecosystem is moving

A very interesting paper (I said "intesresting", I didn't say I
agree!) on open networks where independant nodes with independently developed programs interoperate thanks to standards. The author claims closed and centralized systemes are better, because they allow faster evolution (he uses security as an example).

Many IETF cases mentioned (XMPP, IPv6, email...)

https://whispersystems.org/blog/the-ecosystem-is-moving/