Re: The ecosystem is moving

Miles Fidelman <> Sat, 14 May 2016 01:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A8C0E12D6C6 for <>; Fri, 13 May 2016 18:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SDqkKL1AKN2t for <>; Fri, 13 May 2016 18:39:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1E8D512D19E for <>; Fri, 13 May 2016 18:39:02 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 59F38CC53C for <>; Fri, 13 May 2016 21:39:01 -0400 (EDT)
X-Virus-Scanned: by amavisd-new-2.6.2 (20081215) (Debian) at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id HZuArOTd2Att for <>; Fri, 13 May 2016 21:39:00 -0400 (EDT)
Received: from Miless-MBP.fios-router.home ( []) by (Postfix) with ESMTPSA id C55CECC5BC for <>; Fri, 13 May 2016 21:38:57 -0400 (EDT)
Subject: Re: The ecosystem is moving
References: <> <> <> <> <> <>
From: Miles Fidelman <>
Message-ID: <>
Date: Fri, 13 May 2016 21:38:57 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------3863F7FC0A0073AAD89247BE"
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 May 2016 01:39:05 -0000

Back to the original point, for a moment:

Stephane Bortzmeyer <> Wed, 11 May 2016 12:58 UTCShow 

> 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...)

My long-standing observation is that the climate has changed.  In the 
early days, there was both "demand pull" for new protocols, and an 
environment that encouraged (and to an extent) funded new protocol 
development and deployment.

Since then, the climate has changed:

- it's very hard to get a new protocol into the ecosystem (there are 
quite a few useful protocols, that simply are not supported)

- the drivers have changed from greater interconnection and 
interoperability (back to the original ARPANET drivers of resource 
sharing and collaboration) - to "can it be monetized?"

It's simply a lot easier to deploy a new SaaS, behind an API, and to 
charge for it, than it is to deploy new protocol infrastructure.

The exception seems to be when there is a strong "forcing function" - 
applied top-down.  DoD Force Transformation & the Command & Control 
Research Program drove new operational models into the military 
environment - into networks, into system specifications, and into 
doctrine.  Examples that come to mind:
- XMPP is widely used for tactical chat
- DIS is widely used to support distributed simulation and training - 
including deployment of persistent training federations
- Tactical Data Links (e.g., Link-16) are all over the place
- DDS is widely used for sensor-weapon linkages
Also of note - NNTP remains widely used on the SIPRNET, at the top of 
the MDMP (Military Decision Making Process)

Another example that comes to mind is the Digital Libraries Initiative - 
which forced a lot standards and protocols for library system 

IMHO, without such forcing functions, the natural tendency is toward 
centralized, proprietary services - and back toward a world of walled 
gardens.  Even in areas where we have a measure of widespread 
interoperability - such as calendaring - we see things like Google 
pulling iCal support - making it ever so much more tedious to schedule a 

Miles Fidelman

In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra