Re: [arch-d] Centralization or diversity

Guntur Wiseno Putra <gsenopu@gmail.com> Sat, 01 February 2020 07:27 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 0015D12004F for <architecture-discuss@ietfa.amsl.com>; Fri, 31 Jan 2020 23:27:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.501
X-Spam-Level: *
X-Spam-Status: No, score=1.501 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, URI_WP_DIRINDEX=3.499] autolearn=no 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 0nWB1Z4cZg-0 for <architecture-discuss@ietfa.amsl.com>; Fri, 31 Jan 2020 23:27:32 -0800 (PST)
Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) (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 1ABCE120018 for <architecture-discuss@ietf.org>; Fri, 31 Jan 2020 23:27:32 -0800 (PST)
Received: by mail-ot1-x344.google.com with SMTP id r16so8900330otd.2 for <architecture-discuss@ietf.org>; Fri, 31 Jan 2020 23:27:32 -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=wBYUtreRou3RK3Q5gExw09u9wmTZ8flN2AR3iWDzWUw=; b=AMBWl3WCSpFUGqtspTEV3yvqklXK7mi35IFSLJEQoYMgMf7z89QV0xSJRWWqMMdQgI YfUi0NINB7Jera2f0dXaH6PgXU/jZs8JlqJ9cX4y7GqAVS4+esp27x93rc4vWQ6aaFcy 2JfOIhkdjWjjoEfcEuCM5iMXBX9IW/sCPUo+fLDIcKi8aiJ2TNBZtpXH28kgU6iF8YHk ObgY9MjUk3jQsOlYIdbVxvHou+Cky61SFGLIRIb2OXQoKLt+vU38TfXEiW2bnkcXCAJZ aNddR0ddMQmgxtswM6rriQjRJQYKDaMYoYtbv/Ly1Lh4HDcmRfxb2JDjzajEdovHiEOQ Qklg==
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=wBYUtreRou3RK3Q5gExw09u9wmTZ8flN2AR3iWDzWUw=; b=pQ+BKAsn3Ko156aVJY1DqwmzoJPemUHV0T4hERTXI4sExcU/xCzoxkASF5LMwUDkcU XxVuUZZwU4SiaOKbB9G5mOrc5J68DqzgoqRkeNSAP1cfO40IWa+ZynP1lukqF21sxFMp sAOqzfahYz1bg0x6yi2dJ0TX74uNUGo5rh5xXdYdTV2ma8rLxaTSiH1Ma0JFAdIs7xfb DGG2Ve5JXSx9aV3y1s5h07TiLR9Lsm6STuNJg04ryZjGZNzv2z9C2Sq2eYwjFYY0jpBV b1dwdPLDPWZaIit7BvsRrj9hZvF1A831jrFq3hIG6xHPaWD43rLFiwG1wsYYExqUz1Eu ItcA==
X-Gm-Message-State: APjAAAXLaizk5rMUvH+QuZwh7a4UkuRP/E5yIhldn4jqJ6Vzc5rZsenQ Xnz0VzDOaGj+YzG54+gAcL93OWdMTxwHRIT2B3s=
X-Google-Smtp-Source: APXvYqy1Vv78ClL2wZ7kYcgv02HEdl84lNhflCNR+0xZph/kKN2FjsmIgSezrIOJNYoan879YXV4wem+mbwikKXD/SU=
X-Received: by 2002:a9d:831:: with SMTP id 46mr10858287oty.295.1580542051167; Fri, 31 Jan 2020 23:27:31 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:6830:1155:0:0:0:0 with HTTP; Fri, 31 Jan 2020 23:27:30 -0800 (PST)
In-Reply-To: <CAKi_AEt93FcU+NucYndOLTkCo6hkMXf-_6Q7YHhhHLpnVX2Sew@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> <CAKi_AEum0ciH5JsdQeRFmNig6fS4EnjYTs3cRVR37Q4s+OF9NA@mail.gmail.com> <CAKi_AEt93FcU+NucYndOLTkCo6hkMXf-_6Q7YHhhHLpnVX2Sew@mail.gmail.com>
From: Guntur Wiseno Putra <gsenopu@gmail.com>
Date: Sat, 1 Feb 2020 14:27:30 +0700
Message-ID: <CAKi_AEtd+DPo9NuhM2n4+rn3SaCBw6XZVAHG-n-_7spQbgZTWw@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="000000000000833302059d7e9f8e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/8uIjJa9BpS0KP1Bk-p8gVobvP6Q>
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: Sat, 01 Feb 2020 07:27:35 -0000

Dear architecture-discuss,

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 <gsenopu@gmail.com> menulis:

> 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-ConsolidationintheInternetEcon
> omy.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 <gsenopu@gmail.com>
> 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/1
>> qsfPOKu2TqbmstHg6UOAfU7NoM
>>
>> https://mailarchive.ietf.org/arch/msg/architecture-discuss/l
>> P1_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
>>>>>
>>>>