Re: [arch-d] Centralization or diversity

Guntur Wiseno Putra <gsenopu@gmail.com> Fri, 17 January 2020 07:50 UTC

Return-Path: <gsenopu@gmail.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A3F1207FC for <architecture-discuss@ietfa.amsl.com>; Thu, 16 Jan 2020 23:50:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 M-_DOAga9c4C for <architecture-discuss@ietfa.amsl.com>; Thu, 16 Jan 2020 23:50:36 -0800 (PST)
Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 20FF9120273 for <architecture-discuss@ietf.org>; Thu, 16 Jan 2020 23:50:36 -0800 (PST)
Received: by mail-ot1-x32f.google.com with SMTP id 77so21818104oty.6 for <architecture-discuss@ietf.org>; Thu, 16 Jan 2020 23:50:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GyFk986cX8c7Rkgh+txBJjeJ8Ba05DVc/osekxZ0Lcg=; b=aJxW1Dp7BTOu3OitsDOo7yP9eqC/CfXAek9Bc+Ln1KRVZwxtc9eEjKzYfYz7cbB9KQ a6wUxClbGYVAe/XVGuZVUM93krQbv0vC1BhmkJFwGXslA7ly/tKqEVwOQOJ0VJO9mFPI r8H4cE65mpImXlgL7pufIpVcqQJhXy4QTkU4Y9uaJQoAc4xZiiCEM+1KIvUfhQbwDTKz eeaIogp5XyRCHiBwy5davDAq3F8u5gV1zsDscqCnrOZscMDGk/feYhBXQ/kkMtQxPxH6 YZquyi/kGmpdfs8spsEovtmAiHvoVYVTV+1dRfbk2lgoq7pRAXGZLSo/ZAu24pnvgjeM vrCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GyFk986cX8c7Rkgh+txBJjeJ8Ba05DVc/osekxZ0Lcg=; b=pUA7CSKvnvl9TiGFzlzdfg6JUTvja7WJIDbdUcQCFXI2RF3rg4JQMeG6HvDNT7DBh/ NkwL/pCTK+zFG7yGYavejpEpXSLxoWJh+CII5VPsxzsmuuuzejukL0GKDQ9MKCyDjtQg nTdTsVpES6j0YkE/lUj6YOiedCPjTqurCLqXtqcaEBwpKTkr6fhAHNf4LS4FjcYFQxf+ wQgIETZ/uf8vZpJDRRj8RE6nUSf7Mm2T8QwQmIpeLt4I5tqJvpw8srsbC2/bEocKUmTR HztwQBJ4C4ZwgZQgGGPG7mRlCoaZUBPwpAIi4b3zP7S49b/TNHHqWtyGACWvef+5363A JOgA==
X-Gm-Message-State: APjAAAUZZjHCAJwf8wpbCyCYTwAOaOGVmQhOhWDTYeq6Cinh8fwwzCKy lEfNE/7bujpQyFex8YOSnIcKHBxA+9mcP/feaWw=
X-Google-Smtp-Source: APXvYqx8NAvcugBfDv+auQCCVRce2dxoR5yOkvkZqltsaDYRGVDK/Hhd98Lfw/QU9VkRP6LKJF2cSXNeMHtBdKvwqck=
X-Received: by 2002:a9d:198b:: with SMTP id k11mr5351279otk.295.1579247435340; Thu, 16 Jan 2020 23:50:35 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Thu, 16 Jan 2020 23:50:34 -0800 (PST)
In-Reply-To: <CAKi_AEtexJOQUU=0JjpdeRYoJ=TSQmjgH4hD9vOkPD6hjvV-KA@mail.gmail.com>
References: <LO2P265MB0573A1353911BFDD554DE5C8C2760@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <CAKKJt-dtX4kceJqY4kaB-vg4rs0uEn01SyyzR4m+UAO_0bZ=7g@mail.gmail.com> <c2633b3d-d114-217a-efca-2002bca9a084@gmail.com> <2D994CF8-8C96-405B-A4EF-65672EF31031@tony.li> <20200108182816.GS8801@faui48f.informatik.uni-erlangen.de> <60CB9CB1-590D-4DCD-963C-E34B8F40EA64@tony.li> <20200108192553.GV8801@faui48f.informatik.uni-erlangen.de> <FDE60F88-DD22-4209-8415-76C6FB3C15F9@tony.li> <265A560E-F07F-4CB8-8D5F-6077D1419CE5@comcast.net> <20200109094537.GY8801@faui48f.informatik.uni-erlangen.de> <CAKi_AEtA9S+gfeAUFTctEtDgFseh0KFT_3+Qq3=8AzySpL08vQ@mail.gmail.com> <CAKi_AEtexJOQUU=0JjpdeRYoJ=TSQmjgH4hD9vOkPD6hjvV-KA@mail.gmail.com>
From: Guntur Wiseno Putra <gsenopu@gmail.com>
Date: Fri, 17 Jan 2020 14:50:34 +0700
Message-ID: <CAKi_AEum0ciH5JsdQeRFmNig6fS4EnjYTs3cRVR37Q4s+OF9NA@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: John Day <jeanjour@comcast.net>, Andrew Campling <andrew.campling@419.consulting>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000655f1c059c51327a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/kaaM6wG2MxbxSQ-HaltUolzit_M>
Subject: Re: [arch-d] Centralization or diversity
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2020 07:50:41 -0000

Dear architecture-discuss,

I think these posts have relevances, as approaches and perspectives (for
interpretations and evaluations), to this issue "Centralization or
Diversity ("Centralized Architecture of Internet Infrastructure") ": They
were about "Networks of Interests in Cyberspace, in Internet" and
 "Aesthetics and Ethics of Cyberspace, of Internet" with a horizon of
layers of the social and engineering:

https://mailarchive.ietf.org/arch/msg/architecture-discuss/1qsfPOKu2TqbmstHg6UOAfU7NoM

https://mailarchive.ietf.org/arch/msg/architecture-discuss/lP1_e4ZqEYkNTFlb6N6fommrGy0


Regard,
Guntur Wiseno Putra

Pada Jumat, 10 Januari 2020, Guntur Wiseno Putra <gsenopu@gmail.com>
menulis:

> Dear architecture-discuss,
>
> Adding what I mentioned in the previous message (in trying to learn on
> "Networks conditions"):
>
> "diversity/heterogeneity" seems contradictory to "centralization" when the
> latter is about "uniformity"...?
>
> Of "blobs" (1) there are moments of active elements or primitives, a
> corresponding force of attractions, of fusions, of inflection, and of
> deformations: Does "centralization" in Internet infrastructure not
> represent those moments...?
>
> Thinking also about disciplinary interactions (thus, moments of
> disciplines) having a moment of complexity and flexibility: does such an
> analogue works for "networks conditions" to say that moments of diversities
> have also moments of uniformities...?
>
>
> (1) The quotation is fully presented below (it is how Brian Massumi define
> what Greg Lynn speaks as "blob"):
> "active elements or 'primitives' which combine to generate their own
> space. Each blob is differentiated. It is assigned (by the programmer) a
> circumference, a mass, and a corresponding force of atttaction. The force
> of attraction defines a field of influence outside the perimeter of the
> blob, and that field is in turn differentiated into zones. Closest to the
> perimeter is a zone of fusion. Any blob entering it will combine with the
> first blob to form a larger blob. Beyond the fusion zone is a zone of
> inflection, the area within which the atttactive force of the blob will
> alter the shape, and therefore the field of influence, of a neighbouring
> blob. Put a number of blob together, and their differential influenced on
> each other produce unpredictable reciprocal deformations. (Massumi 1995)
>
>
> Regard,
> Guntur Wiseno Putra
>
> Pada Jumat, 10 Januari 2020, Guntur Wiseno Putra <gsenopu@gmail.com>
> menulis:
>
>> Dear architecture-discuss,
>>
>> (It seems contradictory yet happen: "centralization" to
>> "diversity/heterogeneity" as a network condition...?)
>>
>> Toward the problematic issues on "centralization" on Internet practice,
>> such a way to arrive there is about (re)considering "network conditions":
>> here we meet with diversity/heterogeneity as the Internet draft mentioned
>> "Centralized Architecture on Internet Infrastructure". What does it mean by
>> "centralization" thus...? --how does it work/mean/value for
>> diversity/heterogeneity...?
>>
>> For diversity/heterogeneity as a network condition we may refer to
>> "liquid architecture" (1) of which other things with nuances deserve to
>> mention: "bloobs"(2), "plasm"(3), "plasmatic"(4) and "plasmatics"(5). Thus
>> we are also  saying about a spatial analysis of a network condition as it
>> is about cyberspace, about Internet --and we may plan things strategically
>> about the space...
>>
>> - we may think of Internet as one among other collective matters yet it
>> is also one among other personal matters:  those matters are maintaining
>> dialogues. Is it not so...in considering Internet sustainability? --at
>> least we find that Internet has a significance for planning societies of
>> nations initiated by the United Nations (see "Leveraging Tech...")
>>
>>
>> (1) "...Liquid architecture makes liquid cities, cities that change at
>> the shift of a value, where visitors with different backgrounds sec
>> different landmarks, where neighborhoods vary with ideas held in common,
>> and evolve as the ideas mature or dissolve". (Novak, Marcos, "Liquid
>> Architecture in Cyberspace" (1991)
>> https://www.evl.uic.edu/datsoupi/coding/readings/1991_Novak_Liquid.pdf)
>>
>> (2) "bloobs" refers to "active element or primitive generatiing their own
>> spaces... (with possibilities of) unpredictable reciprocal deformations".
>> (Massumi, Brian, "Interface and Active Space",  in Cheetam, M. A, "Kant,
>> Art and Art History: Moments of Disciplines, Cambridge University Press,
>> Cambridge et all., 2001, p. 25; Cheetam refered Massumi's "Interface and
>> Active Space: Human-Machine Design" available at http://www
>> anu.edu/HRC/first_and_last/links/massumi_works.htm)
>>
>> (3) plasm refers to "a mould of matrix in which something is cast or
>> formed"; "plasma" refers to "living matter of a cell" and to "liquid part
>> of blood in which corpuscles float"; then, plasmatic refers to what is
>> related with "plasm" or "plasma". "Plasmatic" may be applied to refer to
>> "disciplinary interactions ...(having) ...multidimensional and shifting
>> cultural intensities, and that the specific contours of this matric are
>> inflected historically by the forces of which it is comprised ... (--) ...a
>> model of complexity and flexibility allowing us to understand how an active
>> element in the system... can shape and be shaped by disciplines. (Cheetam,
>> M. A, "Kant, Art and Art History: Moments of Disciplines, Cambridge
>> University Press, Cambridge et all., 2001, p. 25)
>>
>> Regard,
>> Guntur Wiseno Putra
>>
>> Pada Kamis, 09 Januari 2020, Toerless Eckert <tte@cs.fau.de> menulis:
>>
>>> Good insights about the outcome of PICS.
>>>
>>> To clarify, i am primarily interested to see if we can do something
>>> to better support static network planning and protocol evolution.
>>>
>>> Something which is more a self-declaration than a (broken) conformance
>>> suite "verified" testing result. Something which always must be
>>> followed by appropriate testing (interop, deployment) depending
>>> on the goal. But something that can help to faster get to that
>>> step. Something to to help avoid horrenduously repetitive RFP questions
>>> by poor customers (does your IETF FOO protocol on your product support
>>> the optional BAR feature).
>>>
>>> One could think of another axis of information in our yang models,
>>> a subset of "implementation defined" behavior whose values can be
>>> statically exposed without access to a live system and hence be
>>> published and then used in netork planning for example
>>> (or auto-collection by a curious WG trying to progress some
>>> standard to full internet ;-)).
>>>
>>> I was interested in the type of information i remember to have seen
>>> in the 90th in PICS, i am horrified about the process i learn
>>> about it here in te thread ;-)
>>>
>>> Cheers
>>>     Toerless
>>>
>>> On Wed, Jan 08, 2020 at 04:49:46PM -0500, John Day wrote:
>>> > FWIW, there were also problems with keeping the test suites up-to-date
>>> with the errata.  Bugs could be fixed in the standards and incorporated
>>> into implementations faster than the people developing the test suites
>>> could keep up (or wanted to). Of course the fixes were in the
>>> implementations before they were in the standards. And what was worse, when
>>> pointed out to them that their test-suited didn???t conform to the spec,
>>> they didn???t care. They still insisted they were right.
>>> >
>>> > For some standards, it was possible to develop utilities that did a
>>> specific function and used part of a standard to do that function but
>>> didn???t need the rest of the standard. But the people running the test
>>> suites couldn???t deal with it. If it didn???t implement the entire
>>> protocol, it didn???t pass. The utility couldn???t cause any of the rest of
>>> the protocol to be generated. It conformed to the standard for everything
>>> it did. They were using the standard as it had been intended.
>>> >
>>> > But the testers were effectively bean-counters and totally stupid.
>>> >
>>> > Conformance fell under the ANSI committee I chaired and I remember
>>> writing them (some military base in Arizona whose name I have thankfully
>>> forgotten) nasty letters telling them to get their act together or get out.
>>> They were doing more harm than good. Wish we had known about the IS-IS
>>> issues as well to add to the list.
>>> >
>>> > One needs some way to test implementations before trying them live.
>>> But one has to treat them (and it has to be instilled in the testers) that
>>> the purpose is to help:  obey Postel???s rule, find problems, and then
>>> determine whether it is the tests, the ???standard??? or the new
>>> implementation that is at fault. And above all if it isn???t externally
>>> visible, it is none of the tester???s business.  Even if there is ???formal
>>> specification???, one can???t be sure that a bug is in the prose, the
>>> formal spec, the tests, or the implementation. They are all suspect. (Often
>>> formal specifications are more complex than the code. And we know what that
>>> means!)
>>> >
>>> > Years before the standards issues arose, I did a survey of testing
>>> methods for our own use. I expected to find that two or three were pretty
>>> effective, pick one or two.  What I found were 20 or 25 that were all
>>> pretty effective and the advice was pick 2 or 3 and it didn???t really
>>> matter which ones as long as they were different. (Not the result I was
>>> looking for.)  ;-)
>>> >
>>> > Take care,
>>> > John
>>> >
>>> > > On Jan 8, 2020, at 15:58, tony.li@tony.li wrote:
>>> > >
>>> > >
>>> > >> Yes, i was thinking of ISO PICS. But i lost track of those ISO
>>> standards
>>> > >> since the 90th. I guess i would have to see a successfull and still
>>> > >> currently used standard and how its PICS do or do not help. Just
>>> > >> not alot of those ISO specs left in wide deployments, right.
>>> > >> X.500 ? Maybe i can get more insight from the security community.
>>> > >
>>> > >
>>> > > You need not go that far.  Remember IS-IS?  Still thriving.
>>> > >
>>> > > And yes, my experience with PICs and test suites comes from that.
>>> > >
>>> > >
>>> > >>> What it does do is to encourage people to write ???conformance
>>> test suites???.  These then get sold to unsuspecting customers and
>>> end-users.  Unfortunately, the quality of such suites is so low that you
>>> spend way, way, way more time debugging the test suite and you never find
>>> bugs in your implementation.
>>> > >>
>>> > >> This is just the worst possible outcome, and i am sure one can learn
>>> > >> from those bad experiences. Just think of taking a more organized
>>> > >> step towards being able to collect protocol implementation
>>> information
>>> > >> from the industry. Right now every WG who wants to raise the level
>>> of
>>> > >> an IETF protocol, e.g.: to(wards) full standard is coming up with a
>>> > >> questionaire in an ad-hoc fashion (we're just doing this in
>>> Multicast
>>> > >> for IGMP/MLD).
>>> > >
>>> > >
>>> > > You can do that if you like, but the one proven, effective method is
>>> interoperability testing.
>>> > >
>>> > > Running code trumps questionaires, conformance test suites, theory,
>>> and mandate.
>>> > >
>>> > >
>>> > >> My point was: If the only murphy you have is competitive pressure,
>>> it works not
>>> > >> it there is only limited competition, such as a total of maybe no
>>> > >> more than 3 competing national infrastructures.
>>> > >
>>> > >
>>> > > And countries that stifle competition inflict vendor lock on
>>> themselves.
>>> > >
>>> > >
>>> > >> See above. The best i think we (IETF) can do is to educate better
>>> about
>>> > >> this by appropriate documents. Certainly some additional protocol
>>> work
>>> > >> will result from that. I for once had simple slides 10 years ago
>>> how to fixup
>>> > >> non-dual plane networks to be dual-plane. And maybe we can come up
>>> with
>>> > >> questionaires to get better numbers from actual deployments (the
>>> > >> PICS discussion).
>>> > >
>>> > >
>>> > > The IETF???s job is not education. It does not work as the education
>>> is not requested
>>> > > and not welcome. The IETF???s job is standards and it needs to focus
>>> on that.
>>> > >
>>> > >
>>> > >> Figuring out ideas for a complete ecosystem of monetization and
>>> > >> deployment between competition and regulation is better left for
>>> > >> an ongoing bar-bof with emphasis on bar.
>>> > >
>>> > >
>>> > > I concur. Let???s stop fooling ourselves into thinking that anything
>>> that the IAB/IETF writes has any impact
>>> > > on regulation or economics.
>>> > >
>>> > >
>>> > >> Actually one of the interesting conclusions was that dual-plane in
>>> > >> many cases is really free but deployments often just don't fully
>>> > >> utilize it.
>>> > >
>>> > >
>>> > > I???d agree that it???s close to free.  If you accept that you need
>>> a dual-plane approach for resiliency, then
>>> > > adding a second vendor to the mix is relatively easy. There???s
>>> additional cost because of decreased
>>> > > purchasing volume. There???s additional costs in management and
>>> operations.
>>> > >
>>> > > However, as compared to the costs of an unnecessary outage, it???s
>>> still trivial.
>>> > >
>>> > > Tony
>>> > >
>>> > > _______________________________________________
>>> > > Architecture-discuss mailing list
>>> > > Architecture-discuss@ietf.org
>>> > > https://www.ietf.org/mailman/listinfo/architecture-discuss
>>>
>>> --
>>> ---
>>> tte@cs.fau.de
>>>
>>> _______________________________________________
>>> Architecture-discuss mailing list
>>> Architecture-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>>>
>>