Subject: [RAM] (de)centralised or distributed

From: JFCM <[email-masked]>
Date: Sat, 30 Dec 2006 14:48:39 +0100

Sorry for the typos. I also answer two private remarks/questions.

At 19:28 29/12/2006, Tony Li wrote:
>>Wouldn't a useful design principle be to favor local concepts over
>>global ones ?
>
>Not if you're trying to address global issues.

We are trying to address global issues from a local diversity point 
of view, not any more from a single united network point of view. 
This is the difference between (de)centralised and distributed (user 
centric) architectures. Question is to understand if a better 
decentralisation is possible or if we must switch to a _distributed_ 
approach. This will have consequences on the architecture, the IETF, 
and the Internet culture and governance. This is not a small thing, 
but IMO the network development is such that decentralised (unique 
network centric) solutions have become too complex (and then insecure 
what increases their complexity).

In cases under debate, why would everyone's routing be the same? why 
would everyone's naming by the same? why would a solution be the only 
IESG approved solution? Containing diversity is a layer violation by 
the network of networks, which can only be addressed by a 
decentralised architecture of networks of the network of networks.

The IPv6 experience shown that having a solution B to replace a 
solution A is not easy to deploy: we need a constant evolution of 
function A staying consistent with the constant evolution of all the 
other functions (namings, routings, addressings, transportings, 
etc.). This can only lead to an increasing diversity, hence 
granularity. Rough consensus is then meaningless (except locally). It 
must be replaced by concerted standards interoperability, based upon 
a multiconsensus over an underlying normative model. This means that 
IAB should attempt to document the observation of the digital 
ecosystem and the needs of its users/co-owners. The job of IETF is to 
document the accidental solutions which belong to the standards' area.

jfc  

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram