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

[Toerless Eckert <[e-mail]>]

On Fri, May 05, 2023 at 07:37:57PM +0200, David R. Oran wrote:
> > 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.
> > 
> 100% agree, although it might be worth pondering if the IAB could provide
> useful data and advice on the technical c consequences of postulated
> anti-trust law/policy or regulations.

I would prefer for such work to be done in a more open IETF community than
how IAB can do work. From the organizational options we have, an IRTF RG would
be most appropriate IMHO, similar to HRPC, although with more focus on
collection of data and bringing it to the community for review than on trying
to offer guidance (at least initially).

Cheers
    Toerless

> Possibly…
> 
> > Regards,
> > Tony
> > 
> > 
> > > On May 5, 2023, at 9:47 AM, Christian Huitema <[e-mail]>
> > > 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
> > > > > <[e-mail]> 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
> > > > > [e-mail]
> > > > > 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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/architecture-discuss
> > > 
> > > _______________________________________________
> > > Architecture-discuss mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/architecture-discuss
> > 
> > _______________________________________________
> > Architecture-discuss mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/architecture-discuss
> DaveO

> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss


-- 
---
[e-mail]