Re: [arch-d] Centralization or diversity

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

Dear architecture-discuss,



The Feasible:
Aesthetics and Ethics of the Internet Architecture...?


Actualities to consider: what are called "consolidation in the Internet
economy" or "concentration in open protocols" or "Centralized Architecture
of Internet Infrastructure" (1).


To the actuality mentioned above, feasibility of protocols is about
particular cases and contexts and solutions when aesthetics and ethics of
(social and technical/the Internet) environments is to be the plan: that is
what we find in one of the past/2013 IAB "Framework for Analyzing
Feasibility of Internet Protocols" (Leva, T. & H. Suommi): It proposed
steps to deal with/to attempt an analysis of the feasibility of protocols
of which it mentioned about "technical architecture", "value networks" and
"deployment environment" in its steps. (2)





(1) https ISOC
https://future.internetsociety.org/2019/wp-content/uploads/sites/2/2019/04/InternetSociety-GlobalInternetReport-ConsolidationintheInternetEconomy.pdf

Sullivan, Andrew, "Three Kinds of Concentration in Open Protocols",
IAB-DEDR Workshop 2019
https://www.iab.org/wp-content/IAB-uploads/2019/05/p7-sulllivan-three_kinds_concentration_ajs_dedr.pdf

Arkko, Jarri, "Centralized Architecture inInternet Architecture", Internet
Draft, 2019
https://www.ietf.org/id/draft-arkko-arch-infrastructure-centralisation-00.txt


(2)
https://www.iab.org/wp-content/IAB-uploads/2013/06/itat-2013_submission_4.pdf
It is part of the IAB-ITAT 2013
https://iab.org/activities/workshops/itat/
To add, there are meanings and values in human existences/experiences;
here, "value networks" is a similar phrase to "networks of interests"
--among others aesthetic and ethic ones and socio-economic ones mentioned
in "Protocol Design and Socio-economic Realities" (Kurtscher, D. in the
IAB-DEDR Workshop 2019)
https://www.iab.org/wp-content/IAB-uploads/2019/05/p14-kutscher-internet-design-kutscher.pdf


Regard,
Guntur Wiseno Putra

Pada Jumat, 17 Januari 2020, Guntur Wiseno Putra <[e-mail]>
menulis:

> 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 <[e-mail]>
> 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 <[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
>>>>
>>>