Subject: Re: [arch-d] Centralization or diversity

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 7 Jan 2020 10:22:56 -0600

I see that this topic is fragmenting into different threads, which is fine,
so I'm not sure where I should insert this comment, but when we're talking
about "centralized" and "decentralized", it's worth noting that
"decentralized" fault tolerance can trip over implementation errors that
are common across many devices owned or operated by a centralized entity.
One of the largest SS7 outages in the US happened in 1990, when a one-line
error that was present in a large number of switches caused >50 percent
call failures across the entire ATT network.

So, implementation diversity matters, not just decentralization.

There's a nice write-up at
http://users.csc.calpoly.edu/~jdalbey/SWE/Papers/att_collapse.html, that
matches my recollection of reports at the time.

For me, the money quote was

When the destination switch received the second of the two closely timed
messages while it was still busy with the first (buffer not empty, line 7),
the program should have dropped out of the if clause (line 7), processed
the incoming message, and set up the pointers to the database (line 11).
Instead, because of the break statement in the else clause (line 10), the
program dropped out of the case statement entirely and began doing optional
parameter work which overwrote the data (line 13). Error correction
software detected the overwrite and shut the switch down while it could
reset. Because every switch contained the same software, the resets
cascaded down the network, incapacitating the system.

Best,

Spencer

On Wed, Nov 13, 2019 at 12:57 AM Andrew Campling
<[email-masked]> wrote:

> "Martin Thomson" <[email-masked]* <[email-masked]>> wrote on Tue,
> 05 November 2019 22:58:
>
> The draft specifically calls out the notion of a single point of failure
> being a problem.  But my experience with centralized services is that they
> aren't centralized in the fault tolerance sense.  If I look at the big
> services, that scale is only achieved with careful distributed systems
> design.  Name any modern service of even modest scale and you generally
> find excellent fault tolerance.
>
> I thought that the document made it quite clear that it wasn’t
> specifically referring to a single point of failure in a technical, fault
> tolerance sense.  In fact it made this clear by, for example, also
> highlighting issues such as “administrative or governance system can become
> weak through too much power or imagined power concentratred in one place”.
>
> Finally, I don't like the emphasis on DNS in this document.  It only
> serves to sensationalize.
>
> I thought that the reference to DNS was particularly helpful given one of
> the potential side-effects of the push behind DoH could be to centralise
> what is currently a highly decentralised system.  I agree with the comment
> in section 4 that “where such centralised points are created, they will
> eventually fail, or they will be misused through surveillance or legal
> actions regardless of the best efforts of the Internet community.  The best
> defense to data leak is to avoid creating that data store to begin with”.
>
> In addition, noting the references to RFC 1958 and RFC3935, I believe that
> it would be prudent for RFC8484 to be reviewed accordingly.
>
>
> *Andrew*
>
>
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 7 Jan 2020 17:53:01 +0100

> call failures across the entire ATT network.

Do i hear a slight criticism/concern about most networks current SDN ==
centralized intelligence & failure dependency ? Or is it just me ?

> So, implementation diversity matters, not just decentralization.

I think i had mentioned this already in the very beginning of the
discussion.

Btw: The historic often cited cause for as much as half-country wide
Internet service outages in Germany was broken Radius/Accounting servers.
Of course, when there was volume accounting you could not make money
when those servers where broken, but even when the accounting models
changed did these issues/dependencies persist if i remember correctly.

In other words: design-wise you need to make sure you have distributed
resilience up to lets say "cash-registers" that can still ensure service
that still work under failure are also still accounted and charged for.

Aka: distributed "routing" and other lower layer resilience
is not sufficient in a commercial environment. And i can not remmber
that DoD/Arpanet ever tried to fund research into these commercial
issues. 

> cascaded down the network, incapacitating the system.

Yes. I think the low-level analysis of newer incidents of this type can
not be that easily explained anymore. A few years back, there was a big 
breakdown in google from too many conflicting automation systems if i remember
correctly. Try to explain in detail how that worked...

Cheers
    Toerless

> > I thought that the document made it quite clear that it wasn???t
> > highlighting issues such as ???administrative or governance system can become
> > weak through too much power or imagined power concentratred in one place???.
> >
> > in section 4 that ???where such centralised points are created, they will
> > defense to data leak is to avoid creating that data store to begin with???.
> >

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Jan 2020 08:46:18 +1300

On 08-Jan-20 05:22, Spencer Dawkins at IETF wrote:
...
> So, implementation diversity matters, not just decentralization. 

Well yes, and this has been understood in high reliability design for at least 30 years. Triple redundancy with diversity are the buzzwords. This was very familiar to me when I worked in control systems, longer ago than I wish to remember. Google will find you examples from the 1980s in computerised nuclear reactor control systems**, and I think the same technique was used in spacecraft control from a very early stage.

It's not quite clear how to enforce this via the IETF, beyond the multiple interoperable implementations of RFC6410.

   Brian

** e.g. https://inis.iaea.org/collection/NCLCollectionStore/_Public/17/069/17069159.pdf

---

From: [email-masked]
Date: Tue, 7 Jan 2020 13:35:45 -0800

> It's not quite clear how to enforce this via the IETF, beyond the multiple interoperable implementations of RFC6410.

The IETF has no police force, thankfully, so enforcement is out of question anyway.

The good news, however, is that Murphy does have a police force and has demonstrated repeatedly that genetic diversity in a network is a Very Good Thing.

Several ISPs who have learned this lesson the hard way have dual planar networks where plane 1 is all vendor A and plane 2 is all vendor B.

Some others still have to learn this.  One of the good things that might come of this effort is to write this down.

Tony

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 8 Jan 2020 09:29:31 -0600

Hi, Tony,

On Tue, Jan 7, 2020 at 3:35 PM <[email-masked]> wrote:

>
> It's not quite clear how to enforce this via the IETF, beyond the multiple
> interoperable implementations of RFC6410.
>
>
>
> The good news, however, is that Murphy does have a police force and has
> demonstrated repeatedly that genetic diversity in a network is a Very Good
> Thing.
>
> Several ISPs who have learned this lesson the hard way have dual planar
> networks where plane 1 is all vendor A and plane 2 is all vendor B.
>
> Some others still have to learn this.  One of the good things that might
> come of this effort is to write this down.
>

Thanks - that was my hope :-)

Spencer

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 8 Jan 2020 19:28:16 +0100

> The IETF has no police force, thankfully, so enforcement is out of question anyway.

Indeed. And i have little opinions about enforcement other than
"SEP - Somebody Else's Problem (not IETF)"

Nevertheless: I think it would help for IETF to have something like
"(protocol/solution/...) implementation compliance specifications"
that would better help for external parties to vet/measure
implementations/deployments against what the IETF envisions.

And where to go from vetting/measured merics, i don't care (yet).

> The good news, however, is that Murphy does have a police force and has demonstrated repeatedly that genetic diversity in a network is a Very Good Thing.

Give or take the absence of competition due to the huge capital
investment requirements.

> Several ISPs who have learned this lesson the hard way have dual planar networks where plane 1 is all vendor A and plane 2 is all vendor B.

*yawn*. Sorry, but coming from financal (services) networks, that had
this since the 1990th, what you are saying now is like saying
"Fred Flintstone now has upgraded to a color CRT TV".

Btw: To stick to my theme of identifyin single points of failures:
around 2010 or so, national financial service (in some unnamed country),
had actually two separate planes. But built a single management plane. I think
you can guess where this story goes. The fun part with the financial
services community is how they can immediately come up with all
type of financial loss number for every period of non-availability
of network services (in units of millions of dollars).

> Some others still have to learn this.  One of the good things that might come of this effort is to write this down.

One should also remember that the cost of dual-plane may be vastly
different based on the density and structure of the country and
underlying infra (fiber trunks, power supplies, etc..). Countries
like USA and china are a lot more interesting/challenging than the
typical european country.

Cheers
    Toerless

---

From: [email-masked]
Date: Wed, 8 Jan 2020 10:53:01 -0800

Hi Toerless,

> implementations/deployments against what the IETF envisions.

Nope. Been there and tried that.  ISO has PIC statements that are pretty much that for their standards.  Did not help at all.

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.

> Give or take the absence of competition due to the huge capital

Customers who buy into single vendor architectures are inflicting vendor lock on themselves.

> "Fred Flintstone now has upgraded to a color CRT TV”.

Good.  Then I’ll say something more controversial: not everyone does it that way, yet.

> typical european country.

Redundancy always has costs.  When it is needed it then pays dividends.  :-)

Tony

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 8 Jan 2020 20:25:53 +0100

> Nope. Been there and tried that.  ISO has PIC statements that are pretty much that for their standards.  Did not help at all.

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.

> 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). 

> Customers who buy into single vendor architectures are inflicting vendor lock on themselves.

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. 

Remember my last mail where repeatedly half countries had no internet
from one of those three providers four many hours because of single
points of failures ?  For years and years. So much for competitive
pressure/Murphy.

Besides, Trump has already concluded that you only need to eliminate
one of the equipment vendors to solve the problem of secure, reliable
national infrastructures.
(not sure what the most fitting emoji is for this paragraph).

> > "Fred Flintstone now has upgraded to a color CRT TV???.
> 
> Good.  Then I???ll say something more controversial: not everyone does it that way, yet.

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).

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.

> Redundancy always has costs.  When it is needed it then pays dividends.  :-)

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.

Cheers
    Toerless

---

From: [email-masked]
Date: Wed, 8 Jan 2020 12:58:13 -0800

> 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.

> questionaire in an ad-hoc fashion (we're just doing this in Multicast

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.

> more than 3 competing national infrastructures. 

And countries that stifle competition inflict vendor lock on themselves.

> questionaires to get better numbers from actual deployments (the

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.

> 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.

> many cases is really free but deployments often just don't fully

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

---

From: John Day <[email-masked]>
Date: Wed, 8 Jan 2020 16:49:46 -0500

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, [email-masked] wrote:
> 
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 08 Jan 2020 20:23:14 -0500

Let me add three small things to John's and Tony's observations
and experience, partially from other areas of standards...

* When there is a test suite that is more or less official
(typically by designation by the SDO that created the standard,
some related body, or just because "everyone" is using it) ,
there is considerably risk of its becoming a substitute for the
standard.  In other words, "conform to the standard" turns out,
in practice, to mean "conform to the test suite" even, or
especially, if the two don't quite align.  John's suggestion of
having a collection of them that are developed independently and
picking 2 or 3 can mitigate that problem significantly but, if
the chosen test suites are completely consistent with each
other, then one is, de facto, back to a de facto official test
suite.

* Empirical experience that parallels the above and observations
others made are the reason why the Internet was build rather
more on reference implementations (good examples but not
intrinsically authoritative) and interoperability testing (if
problems show up, they are issues to be investigated,
understood, and repaired, not the source of extended debates
about who was most correct or most conforming), rather than test
suites.

* John's observation about applying the robustness ("Postel's")
principle to systematic testing has proven very useful and is
something we should keep in mind when people, especially people
with less experience, claim that principle has outlived its
usefulness.

* While the PICS effort, and "PICS proforma"s, are good
candidates for good examples in this area for networking-related
standards, they differ from many other examples because they had
the character of what we would call Applicability Statements
that were often expressed in test suites, i.e., specifications
of what constituted conformance s.t., if something was not in
the PICS, it didn't count.   In broader IT standards areas, the
all-time poster child was probably the Ada programming language
and there is a case to be made that its longevity and brilliant
success when not mandated by law or contracts was largely a
result of implementations designed around passing the test suite
rather than, e.g., actually working.  Neither examples I think
the IETF should follow unless with have a death (or at least
obscurity) wish.

    john

--On Wednesday, January 8, 2020 16:49 -0500 John Day
<[email-masked]> 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. 
> 
> 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
> 
>>> 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.
>> 
>> 
>>>> 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). 
>> 
>> 
>>> 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. 
>> 
>> 
>>> 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
>>

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Jan 2020 10:45:37 +0100

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. 
> 
> 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
> 
> > 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.
> > 
> > 
> > I concur. Let???s stop fooling ourselves into thinking that anything that the IAB/IETF writes has any impact
> > 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
> > 

-- 
---
[email-masked]

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Fri, 10 Jan 2020 00:04:25 +0700

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 <[email-masked]> menulis:

> > 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.
> >
> > 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
> >
> > >>> 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.
> > >>

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Fri, 10 Jan 2020 11:08:01 +0700

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 <[email-masked]>
menulis:

> Active Space: Human-Machine Design" available at http://www
> anu.edu/HRC/first_and_last/links/massumi_works.htm)
>
>> > 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

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Fri, 17 Jan 2020 14:50:34 +0700

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 <[email-masked]>
menulis:

> "active elements or 'primitives' which combine to generate their own
> space. Each blob is differentiated. It is assigned (by the programmer) a
>> 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
>> (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)
>>> > >>> 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
>>> Multicast
>>> > > I???d agree that it???s close to free.  If you accept that you need
>>> a dual-plane approach for resiliency, then

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Wed, 22 Jan 2020 09:23:23 +0700

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 <[email-masked]>
menulis:

>> "diversity/heterogeneity" seems contradictory to "centralization" when
>> the latter is about "uniformity"...?
>>
>> (1) The quotation is fully presented below (it is how Brian Massumi
>> define what Greg Lynn speaks as "blob"):
>>> (2) "bloobs" refers to "active element or primitive generatiing their
>>> own spaces... (with possibilities of) unpredictable reciprocal
>>> deformations".
>>>> 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
>>>> > > I concur. Let???s stop fooling ourselves into thinking that
>>>> anything that the IAB/IETF writes has any impact

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Sat, 1 Feb 2020 14:27:30 +0700

As it is about this thread of discussion:

"Internet Way of Networking"

Governments are increasingly moving towards sovereignty-based approaches to
the Internet. At the same time, a winner-takes-all global economy means
that a few major gatekeepers have control over Internet data and
infrastructure. Both state and market-driven centralization are risks to
the decentralized Internet way of networking. Centralization encourages
single points of failure and moves away from the open and voluntary set of
standards and practices that have sustained the Internet as a source of
innovation and economic growth. These systemic risks to the global
Internet’s future, and to the Internet Society’s core vision, require a
broad and sustained response....".

It is part of 2020 Internet Society Action Plan Projects:

https://www.internetsociety.org/issues/internet-way-of-networking/

Regard,
Guntur Wiseno Putra

Pada Rabu, 22 Januari 2020, Guntur Wiseno Putra <[email-masked]> menulis:

> https://future.internetsociety.org/2019/wp-content/uploads/sites/2/2019/
> 04/InternetSociety-GlobalInternetReport-ConsolidationintheInternetEcon
> omy.pdf
>
> https://www.iab.org/wp-content/IAB-uploads/2019/05/
> p7-sulllivan-three_kinds_concentration_ajs_dedr.pdf
>
> (2) https://www.iab.org/wp-content/IAB-uploads/2013/06/
> itat-2013_submission_4.pdf
> https://www.iab.org/wp-content/IAB-uploads/2019/05/
> p14-kutscher-internet-design-kutscher.pdf
>
>
> Regard,
> Guntur Wiseno Putra
>
>>>> (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
>>>>> pressure, it works not
>>>>> > > I???d agree that it???s close to free.  If you accept that you
>>>>> need a dual-plane approach for resiliency, then