Re: [arch-d] Centralization or diversity

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

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/firs
t_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
>