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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 04 May 2023 21:39 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 1713DC17CEA6 for <architecture-discuss@ietfa.amsl.com>; Thu, 4 May 2023 14:39:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 gph3Mf-0fqKL for <architecture-discuss@ietfa.amsl.com>; Thu, 4 May 2023 14:39:24 -0700 (PDT)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 56102C17D66C for <architecture-discuss@ietf.org>; Thu, 4 May 2023 14:39:24 -0700 (PDT)
Received: by mail-pl1-x630.google.com with SMTP id d9443c01a7336-1ab0c697c2bso9313855ad.1 for <architecture-discuss@ietf.org>; Thu, 04 May 2023 14:39:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683236363; x=1685828363; 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=6oHaMUxI7D5b5KuJ9+l13Y1dw3KfDkvFbhgQN9oYX3I=; b=dk67Cayq8cejGDkEs4hHoKulSlZxHyTruQoS1fabZgMAXRPrVPTz23il3yxdqOMtMN CjJliPOIoISpYIZ+E1F/nQ4S2IDGGPtco4zf/OigD8sl2ATIdZjr3LhWIu5vICNUjCAL eedOpnsGWrugRohwmwCPPvuBv7fW+P5GpvjdMzAFy5fnnZbZVXKwQAreBAALeyx9Pg2r QtCdBWFX5NFd1ocpwUk4shQaZ0ye+IOdH93iLilRfUKx4D7epcMN3ATUp4zltZ/3ehje E4vbIDA2OkYUvcxZAr1iXv8aPYcr8C2wY1+TICmGA8rpc+8FcOrX9LzdZCjBZQn2sfi3 ZpVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683236363; x=1685828363; 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=6oHaMUxI7D5b5KuJ9+l13Y1dw3KfDkvFbhgQN9oYX3I=; b=k1wVHpSYSy4q8/TF5lI3yh1hbl/WBVLJC/mz8I8e0ODDr4QY5i+gXoqM/PcHKv+MxG QrIH6S1wVXqBSCfj8j3sDl9mgvpfqA5UQCZ/xUFpKVkIR7/haeUhCn2oxhYhPzDT5eUS Eu1+m1g+MJw5Mqmzud4pOwr+A8XCE5tnqvi+ZnfSe73rvTEABKy24V5FWYL8ryozw1mE sdguFXXMtu079GnOU/1LMurrgXvSzAQNlGPDmAzrLik44R7L8Q8HaaBT4zrH94r7aEPq J676gGBbCucWuuqwwR327+FrBIAnHjSXmtQD41a/mfPTGUMSp6qdSFAaa2ZNLH7NHyPs g01A==
X-Gm-Message-State: AC+VfDxkjehO/+jOBWQfU+xyPEnoikz4cs5lP2AJVEzISVYZ+UxAkTQX vDUDcJ7+nSYgX8GXt0F9fh7sz6AHsKXa/g==
X-Google-Smtp-Source: ACHHUZ4o0QzI2AlK5ukyvEIJe2VXJuYEmE8BaEngmb1R2nDHP3RfF2OUh/AM9MINliN0c35Ijnl3AQ==
X-Received: by 2002:a17:903:190:b0:1a2:a8d0:838e with SMTP id z16-20020a170903019000b001a2a8d0838emr5883313plg.61.1683236363218; Thu, 04 May 2023 14:39:23 -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 y7-20020a1709029b8700b001ab00010363sm15431plp.35.2023.05.04.14.39.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 May 2023 14:39:22 -0700 (PDT)
Message-ID: <911c3777-47e0-fad0-b0f9-7cbb81ba5a56@gmail.com>
Date: Fri, 05 May 2023 09:39:17 +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: architecture-discuss@ietf.org
Cc: Internet Architecture Board <iab@iab.org>
References: <0f0da4833f81463b972558d972285595@boeing.com> <12045445-15D9-40F9-8306-4F3F98AB6BBE@apple.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <12045445-15D9-40F9-8306-4F3F98AB6BBE@apple.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/fMZXFP7zTnKzAQhGgw1cTOzloVM>
Subject: [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: Thu, 04 May 2023 21:39:26 -0000

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