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

Hesham ElBakoury <helbakoury@gmail.com> Fri, 05 May 2023 21:31 UTC

Return-Path: <helbakoury@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 DCABEC19E0FF for <architecture-discuss@ietfa.amsl.com>; Fri, 5 May 2023 14:31:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 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, HTML_MESSAGE=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 hDr9ZzW_62bO for <architecture-discuss@ietfa.amsl.com>; Fri, 5 May 2023 14:31:33 -0700 (PDT)
Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 230D2C17CEA7 for <architecture-discuss@ietf.org>; Fri, 5 May 2023 14:31:33 -0700 (PDT)
Received: by mail-pg1-x535.google.com with SMTP id 41be03b00d2f7-52c6504974dso1980725a12.2 for <architecture-discuss@ietf.org>; Fri, 05 May 2023 14:31:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683322292; x=1685914292; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KtaoXF5RgOMoVWOHFowfbKlRunHYsOLcgVl85SgBtt4=; b=FjFEj6nKKqYdT3MiN1AsGjvHMQ5DdeUtshMwfTqgWK8SHj/zvWI1ky0Wl3Pv49foAw YV1l/RtP4w1saNA7WofIfjugE4k5hWeDZFYwQxd1Q/4r5K367WRqvRBJDcF3FviHCYDx 9zTtA9ZgDNh9Vkf2S3BvYoNO+RU+5hruXzBKFIrB3L0CYHJuZ4VoAqINo11uenViT030 NrBqJjhJhQSyjW63DsUibdavNPwGZHLBLMbvfrtt2ATY/doP0QZ6KVMTJwTj3PWc/FAf Ak/t8UieDRgUBLpY+8nAFFrz5QcW00nnvJwWFKDuwd6vtLwgq9xXJdKFcUB5iLbhvUog +fHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683322292; x=1685914292; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=KtaoXF5RgOMoVWOHFowfbKlRunHYsOLcgVl85SgBtt4=; b=WGu8q1JIOnQAq1dGmdVZwmWxWWnVK0FTFqEPa3kTDTpfyaqWpVXrqHwUtNRPowe85/ Po8KO1VGn2tHI1h+Oh83htwfynquFGqkX10V1zzWHIsu3u8wFOy6yM+YdqTLGwOqNmrr SC3Y5RAorJ/izVuv7w0sYIPHn5RCNWsWn/yT352EEKI5xIGTgFuCn4Mhf2pdA5AaYAzz UdxHU98ZcchJpNMR+SjRoKhAwHsotF2cjDuGJ7rNfZc4n/vFfjSHF9i+ZdtWgqPOUuVs oTiYQ9v2TI/z81wNaIBVtHxp6Y/IshyUj7QmwfsbMmeN0YcquDEsmsHTvDNYWZ7neUV0 BbHQ==
X-Gm-Message-State: AC+VfDzghY5HFYCsKEAGREuqj+cZGlizR38uWuOlsQVCtR8eOuDW2vRS JxOmw8Tln09eeQ9mE676ZXL5wJCeA80FCGXrT6Q=
X-Google-Smtp-Source: ACHHUZ6h+MI648Zh4KkcjE6Cn4e20PwGkrN7KU8CYsfDGqke/CC0NF2+G99B6T+W44xE8Rlo0sgPVWVevUnW6ilo9bU=
X-Received: by 2002:a17:90a:a683:b0:23e:f855:79ed with SMTP id d3-20020a17090aa68300b0023ef85579edmr2974587pjq.28.1683322291616; Fri, 05 May 2023 14:31:31 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <8af99305-de33-911a-6fd0-d9bd5f0c2294@huitema.net>
From: Hesham ElBakoury <helbakoury@gmail.com>
Date: Fri, 05 May 2023 14:31:20 -0700
Message-ID: <CAFvDQ9qfSnhMNSN0k3-dghbyOpzhLRFScUCPk6+Fertk3fx_pA@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: Arnaud Taddei <arnaud.taddei=40broadcom.com@dmarc.ietf.org>, Brian E Carpenter <brian.e.carpenter@gmail.com>, architecture-discuss@ietf.org, Internet Architecture Board <iab@iab.org>
Content-Type: multipart/alternative; boundary="0000000000003c015a05faf903a9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/W4mI3VCHgblf8SWxI6Ax9M88hSo>
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 21:31:34 -0000

Which protocol or proposal was not accepted by IETF because it may lead to
Internet fragmentation?

Hesham

On Fri, May 5, 2023, 10:14 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
>