Re: [arch-d] Splintering (fragmentation) vs Centralization vs Users

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 05 May 2023 22:18 UTC

Return-Path: <brian.e.carpenter@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 DDD29C14CE31 for <architecture-discuss@ietfa.amsl.com>; Fri, 5 May 2023 15:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPKhQo5W1HoA for <architecture-discuss@ietfa.amsl.com>; Fri, 5 May 2023 15:17:58 -0700 (PDT)
Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 327EDC152DAD for <architecture-discuss@ietf.org>; Fri, 5 May 2023 15:17:58 -0700 (PDT)
Received: by mail-pf1-x431.google.com with SMTP id d2e1a72fcca58-6436e075166so1819479b3a.0 for <architecture-discuss@ietf.org>; Fri, 05 May 2023 15:17:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683325078; x=1685917078; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=rFcfYIEQeVzR62zqjzsZYOqZD2Aidu27HAWuwfQfKAY=; b=niDLXRMhnqGIIJUYmUL1JqhfC9QE3PdaDtE+7kjZK5ARaET+ZROXz2S4Ggjt/1pYt2 AVeI5G5BCEaqe2Ies1oj2yQHfzaIQGdAc4xDsiQNku9JrrgTpb7H86Mj6IsToqBUjqlM 4QHecSktv7yJ6C4I1JTksQvOwnXEyl3vxCtKWRcxfGlcM5f8yy2mo5uk8w4NvvuIW2+K wfZaMKcQBjli6UHF9IZq9NokZNfcs64AW9/4mrKoumszstztNwJrRnuAzn7Kvj0wL40m soG5XKbsjfwol4I+XlouEoDFLvS1IOhMLSNC0cMvKX0XP54AifVyfhYsVvDgY+mAPgb2 lZnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683325078; x=1685917078; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=rFcfYIEQeVzR62zqjzsZYOqZD2Aidu27HAWuwfQfKAY=; b=EhHHc6VYnqXjLN0b8oavu5sNGQvssmpGEssUOyjxpQebxcPiGjVDQGIxa1u0SKGiWf Z3Q83TIaGxcXdxaBqcruR8BA1cs3h31ssqdnNVHM8RVuj3jx/yFBFyzFaoHXJqgYsqH6 GmAu5osHMBVhrPF2olOOEsKc5nRAd/OxzRuPmQ0b6/lYnVFH/f1DuQToT9zamFXCYue/ FawL9UAdWFEhXifMDXzIwqmpIW/UxQA09ynWPODXFVVuzC9oHNdi2pexQlFsmPIrUAZk SAKJcIwFcbHT5KeaHTO/LB1jeWgALjq3GnOTPrH378HvbLJUX+LTN0r44WPlrEUGiTJK xGqg==
X-Gm-Message-State: AC+VfDwBkCDmALAVWlISezfJGmy501tSmb8XkRHlg3NyJI3uQzAMuaXM /IUfhxX4yJIyTAoccPAeyCE=
X-Google-Smtp-Source: ACHHUZ730+UIcKjFIGxzy2roj9fBlEzvGFKf1XBODEJ9d7I7yYJCPiMrCsmd/ldTp+/nJA5A++faig==
X-Received: by 2002:a05:6a00:23d3:b0:63d:4752:4da3 with SMTP id g19-20020a056a0023d300b0063d47524da3mr4139891pfc.25.1683325077528; Fri, 05 May 2023 15:17:57 -0700 (PDT)
Received: from ?IPV6:2406:e003:1184:f001:9991:d1ad:8c20:42bd? ([2406:e003:1184:f001:9991:d1ad:8c20:42bd]) by smtp.gmail.com with ESMTPSA id r16-20020a62e410000000b006258dd63a3fsm2050505pfh.56.2023.05.05.15.17.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 May 2023 15:17:56 -0700 (PDT)
Message-ID: <56667223-b9cd-6554-092b-66f4ffb6b292@gmail.com>
Date: Sat, 06 May 2023 10:17:52 +1200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Tony Li <tony.li@tony.li>, Christian Huitema <huitema@huitema.net>
Cc: Arnaud Taddei <arnaud.taddei=40broadcom.com@dmarc.ietf.org>, architecture-discuss@ietf.org, Internet Architecture Board <iab@iab.org>
References: <0f0da4833f81463b972558d972285595@boeing.com> <12045445-15D9-40F9-8306-4F3F98AB6BBE@apple.com> <911c3777-47e0-fad0-b0f9-7cbb81ba5a56@gmail.com> <4B5D79EE-062B-480D-AB58-E782476926BB@broadcom.com> <8af99305-de33-911a-6fd0-d9bd5f0c2294@huitema.net> <285E3C91-FD39-4565-A8A7-C32569C05A22@tony.li>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <285E3C91-FD39-4565-A8A7-C32569C05A22@tony.li>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/PGQs_I6p7J11QkIEOiZAhkfe0Ow>
Subject: Re: [arch-d] Splintering (fragmentation) vs Centralization vs Users
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 05 May 2023 22:18:02 -0000

On 06-May-23 05:20, Tony Li wrote:
> 
> Or, perhaps the IAB might want to consider whether or not economic organization is within the scope of the Internet architecture.
> 
> Trying to control the economic forces of the entire planet through a series of RFCs seems quixotic, to say the least.

Of course. I tend to think that RFC1654 has had at least a trillion dollars of unforeseen side-effects, for example.

> 
> Consolidation is part of the natural evolution of any market. Anti-trust legislation has been necessary to ensure consumer protection, as no other mechanisms have ever sufficed. Expecting that we can do better would seem like an act of hubris.

Of course we can't. But that doesn't preclude thinking about the issues in our design process.

    Brian

> 
> Regards,
> Tony
> 
> 
>> On May 5, 2023, at 9:47 AM, Christian Huitema <huitema@huitema.net> wrote:
>>
>> Brian asks: "Is there scope for IAB guidance to the IETF about what aspects of protocols, especially security protocols, might encourage or discourage either centralization or splintering?" I think there is, or more likely, that the IAB (and the IETF) have better find something.
>>
>> Because the alternative position is, "Yeah, we design protocols that can just as well enable decentralization or foster monopolization, be good for society or be atrocious. Whether they do one or the other is someone else's problem." And that sounds very much like "Our job is to put the rockets up. Where they fall, that's another department."
>>
>> -- Christian Huitema
>>
>> On 5/4/2023 11:14 PM, Arnaud Taddei wrote:
>>> Good write up Brian which reminds me 2 things + 1 addition
>>> 1) DINRG had a similar discussion in IETF 116 on the theme "does a new technolog drive those tendendencies?” (This was about centralisation)
>>> 2) We looked at IMAP for example and I reminded a discussion I had perhaps 25 years ago with Bill Yeager and he had a really good metaphor (and that was prior to “social networks” era), which then led me to another such discussion with Mark Crispin (rip)
>>> The addition is that my brain is missing security in the picture as a "superposition state” (and I use Quantum Physics on purpose … not just in memory of our joint past at CERN!) in particular recognising the intrication of privacy and security.
>>> Now I thought initially ‘because defence is creating its own twist here’ but then I realized that to a certain degree this is as well because each of the 3 constituencies of your picture are not just defenders, they are attackers too in multiple forms.
>>> I am not sure (this early morning) if this is a primary level issue or if it is a secondary level issue in your proposal.
>>> Hope this helps a little bit
>>>> On 4 May 2023, at 23:39, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> After a little off-list discussion, I have a few more general thoughts
>>>> on this topic. (I won't identify the other person in that discussion,
>>>> to respect their privacy.)
>>>>
>>>> I mentioned that some security technology that we develop could be
>>>> "dual use", e.g. useful both for privacy and useful for walled gardens.
>>>> So perhaps we should be careful when evaluating new ideas that they
>>>> cannot be used for undesirable purposes as well as the intended purpose.
>>>> If we consider that both excessive centralization and excessive
>>>> splintering (a.k.a. fragmentation) are bad things, does a new technology
>>>> drive those tendendencies? Could we design it differently to avoid
>>>> this?
>>>>
>>>> Is there scope for IAB guidance to the IETF about what aspects of
>>>> protocols, especially security protocols, might encourage or discourage
>>>> either centralization or splintering?
>>>>
>>>> That could be a productive use of the IAB's resources where we might
>>>> have some impact. Discussion of wider societal, commercial and
>>>> political issues in the IAB and IETF would get nowhere, and in my
>>>> opinion is best left to ISOC.
>>>>
>>>> There's very clearly a 3-way tussle, and that makes all discussion
>>>> difficult, especially since each national government has different
>>>> goals. ASCII art:
>>>>
>>>>                 Users
>>>>            (freedom of action,
>>>>                 privacy)
>>>>                 /    \
>>>>                /      \
>>>>               /        \
>>>>       National          Global
>>>>    governments -------- businesses
>>>>    (defend or          (capture &
>>>>     control             exploit
>>>>     citizens &          customers)
>>>>     economy)
>>>>
>>>> Regards
>>>>    Brian Carpenter
>>>>
>>>> _______________________________________________
>>>> Architecture-discuss mailing list
>>>> Architecture-discuss@ietf.org
>>>> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/architecture-discuss&source=gmail-imap&ust=1683841175000000&usg=AOvVaw3DIB56mqn7ZU0a53yuDvJE
>>> _______________________________________________
>>> Architecture-discuss mailing list
>>> Architecture-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>>
>> _______________________________________________
>> Architecture-discuss mailing list
>> Architecture-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/architecture-discuss
>