Re: [arch-d] Centralization or diversity

[Guntur Wiseno Putra <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> 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, [e-mail] 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
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/architecture-discuss
>>
>> --
>> ---
>> [e-mail]
>>
>> _______________________________________________
>> Architecture-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>>
>