Subject: [arch-d] Fwd: New Version Notification for draft-nottingham-avoiding-internet-centralization-00.txt

From: Mark Nottingham <[email-masked]>
Date: Thu, 9 Dec 2021 18:51:10 +1100

Hi arch-discuss,

I wrote some thoughts down about centralisation, taking a somewhat different tack from other work in this area.

I'm not done yet (this is quite rough, handwave-y, and incomplete), but would be interested in feedback/issues/PRs.

Cheers,

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-nottingham-avoiding-internet-centralization-00.txt
> Date: 9 December 2021 at 6:49:37 pm AEDT
> To: "Mark Nottingham" <[email-masked]>
> 
> 
> A new version of I-D, draft-nottingham-avoiding-internet-centralization-00.txt
> has been successfully submitted by Mark Nottingham and posted to the
> IETF repository.
> 
> Name:		draft-nottingham-avoiding-internet-centralization
> Revision:	00
> Title:		Avoiding Internet Centralization
> Document date:	2021-12-08
> Group:		Individual Submission
> Pages:		19
> URL:            https://www.ietf.org/archive/id/draft-nottingham-avoiding-internet-centralization-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-nottingham-avoiding-internet-centralization/
> Html:           https://www.ietf.org/archive/id/draft-nottingham-avoiding-internet-centralization-00.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-nottingham-avoiding-internet-centralization
> 
> 
> Abstract:
>   Avoiding centralization is an important goal for Internet protocols.
>   This document offers a definition of centralization, discusses why it
>   is necessary for Internet protocol designers to consider its risks,
>   identifies different kinds of centralization, catalogues some
>   limitations of current approaches to controlling it, and recommends
>   best practices for protocol designers.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Dirk Trossen <[email-masked]>
Date: Thu, 9 Dec 2021 08:44:21 +0000

Hi Mark,

Many thanks for this draft, which I enjoyed reading. It addresses a timely topic and seems to relate to many of the points Geoff Huston has raised previously (e.g., see https://github.com/danielkinguk/sarah/blob/main/conferences/ietf-112/materials/Huston-2021-11-10-centrality.pdf, a presentation he gave at the IETF112 side meeting on 'service routing and addressing').

I've got a few questions and suggestions:

1.      Do you share Geoff's pessimism (expressed in the above presentation) that it's too late to counter some of the centralization aspects of the Internet?

2.      How do you see works like the recently published SIGCOMM2021 paper on "Decoupling web services" (see https://www.cs.umd.edu/~dml/papers/unbind_sigcomm21.pdf) through your (draft's) centralization lens?

3.      I see item 1 and 2 strongly related since in the chat of the aforementioned side meeting on 'service routing', much of the (here single domain's) centralization has been identified as being driven by the economic situation that has created a perceived abundance of centralized cloud resources. If so, are we beyond the point of no return on this? Or can something be done (technology? Non-technology?)?

4.      More as a suggestion, I wonder if there is more than a historical intention (e.g., citing BCP95) that should be included as a driver to keep decentralization as a key tenet for the Internet? For instance, including forward-looking use cases may point towards the further need for decentralization as a motivation for continued discussion on this important aspect?

5.      While this draft specifically focusses on the centralization aspect, I see a strong relation also to the discussions on the INT area mailing list, instigated as an outcome from the IETF112 side meeting on "Internet Addressing", discussing Dino's questions on "what the user may want from the network" as  a start for a wider architecture discussion.

This last item 5 is key for me since I see this need for a wider discussion that has a number of key threads, starting from, e.g., emergence of limited domains (RFC8799), centralization, features of the network, suitability of current addressing and more. As Dirk Kutscher pointed out in the side meeting mentioned in item 5, a wider architecture discussion may be needed, which in turn may impact the various architectural aspects (like addressing, for instance).

Beyond discussion on this list, I wonder if the time is right for an IAB workshop (which would need careful scoping to be tangible)?

Again, thanks for the draft!

Best,

Dirk
P.S.: BTW, fully agree with your point in Section 4.3 since I've seen too many magic promises for DLTs/blockchains. In an effort within the IIC (Industrial Internet Consortium), we have been working on a whitepaper that describes the "impact of DLTs on provider networks", outlining the chattiness aspect and the resulting waste/inefficiency that you point out. The whitepaper is planned for release in December, i.e., imminently.

From: Architecture-discuss [mailto:[email-masked]] On Behalf Of Mark Nottingham
Sent: 09 December 2021 08:51
To: [email-masked]
Subject: [arch-d] Fwd: New Version Notification for draft-nottingham-avoiding-internet-centralization-00.txt

Hi arch-discuss,

Cheers,

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-nottingham-avoiding-internet-centralization-00.txt
Date: 9 December 2021 at 6:49:37 pm AEDT
To: "Mark Nottingham" <[email-masked]<mailto:[email-masked]>>

Abstract:

The IETF Secretariat

---

From: Christian Huitema <[email-masked]>
Date: Thu, 9 Dec 2021 11:13:24 -0800

> 1.      Do you share Geoff's pessimism (expressed in the above presentation) that it's too late to counter some of the centralization aspects of the Internet?

I think Mark's draft could be improved by analyzing the economic push 
for centralization. Some of the centralization might happen due to 
random forces and weaknesses in the initial design, but lots of it 
result from conscious strategies pushed by investors. To put it briefly, 
investors reward  monopolies, because monopolies end up making way more 
profits than players in competitive markets. The naive entrepreneur who 
has a startup idea will be guided by investors towards being more 
realistic, and looking at strategies to build that startup into a 
dominant player. Those strategies largely sum up to building a monopoly.

The business literature abounds for euphemisms for such monopolization 
strategies. For example, the "blue water, red water" metaphor explains 
entrepreneurs that they should go swim in uncontested territory, blue 
water, rather than where sharks are already feeding, red water. That's 
an euphemism for not trying to compete with existing monopolies. The 
"moat" metaphor explains entrepreneurs that they should protect their 
business through an unassailable moat, just like castles in medieval 
times. Suggested moat building strategies include amassing patents, 
cultivating network effects, and reaching scale quickly before 
competitors have a chance to grab the market. Of course, those 
strategies are not limited to startups. If a division of a large company 
wants to develop a new line of products, it will receive the same 
advice. The entrepreneurs who can convince investors of their potential 
for building a monopoly will be rewarded with large amount of capital. 
Not all of them will succeed, but those who do will indeed evolve to 
dominate their chosen segment of the market.

Historically, monopolies last a long time. Most fail only after decades 
of success engender complacency and bureaucracy, which would mean that 
we are stuck with centralization for decades. The exception would be 
monopolies dismantled by explicit political action, such as the movement 
leading to the Sherman Act, but that is somewhat outside the realm of 
standards.

Faced with that, our moral indignation and our push for virtuous 
standards is likely to fail. We won't get competition if nobody dares 
fight the existing monopolies, or if those who dare regularly get 
crushed. We won't get much standard activism if the engagement against 
monopolies concentrates in the political realm. But we can still try, of 
course. That probably means studying the strategies used to preserve 
monopolies, and setting up to explicitly counter them. Pushing 
technologies that are not blocked by patents, developing standards that 
break interoperability barriers. We should be explicit about that.

-- Christian Huitema

---

From: Eliot Lear <[email-masked]>
Date: Thu, 9 Dec 2021 12:32:16 -0700

I don't think we need to get anywhere near that crass, Christian.  Quite 
frankly scaling and concentration are naturally linked.  And not all 
concentration is bad.  Having a zillion SMTP servers out there is 
probably harming security.  But maybe having – and this will amuse some 
– *additional* layers of intermediation might actually *help* 
decentralization, if for instance, an endpoint can belong to multiple 
agencies.

"Hold my email, servants," can mean pulling from Google, Yahoo!, and 
who-knows-who for the same address.  But allowing some amount of 
cyberprotection to occur in each of those intermediaries. Guess how much 
protocol work is need for that?  Zero.

But it hasn't happened because nobody wants run/manage their own backend 
server.  connecting via imap (or something else) to gmail/yahoo/hotmail 
is enough for much of the world.

Eliot

On 09.12.21 20:13, Christian Huitema wrote:
>> 1.      Do you share Geoff's pessimism (expressed in the above 
>> presentation) that it's too late to counter some of the 
>> centralization aspects of the Internet?
>
>
> result from conscious strategies pushed by investors. To put it 
> briefly, investors reward  monopolies, because monopolies end up 
> making way more profits than players in competitive markets. The naive 
> entrepreneur who has a startup idea will be guided by investors 
> towards being more realistic, and looking at strategies to build that 
> startup into a dominant player. Those strategies largely sum up to 
> building a monopoly.
>
> strategies are not limited to startups. If a division of a large 
> company wants to develop a new line of products, it will receive the 
> same advice. The entrepreneurs who can convince investors of their 
> potential for building a monopoly will be rewarded with large amount 
> of capital. Not all of them will succeed, but those who do will indeed 
> evolve to dominate their chosen segment of the market.
>
> Historically, monopolies last a long time. Most fail only after 
> decades of success engender complacency and bureaucracy, which would 
> mean that we are stuck with centralization for decades. The exception 
> would be monopolies dismantled by explicit political action, such as 
> the movement leading to the Sherman Act, but that is somewhat outside 
> the realm of standards.
>
> monopolies concentrates in the political realm. But we can still try, 
> of course. That probably means studying the strategies used to 
> preserve monopolies, and setting up to explicitly counter them. 
> Pushing technologies that are not blocked by patents, developing 
> standards that break interoperability barriers. We should be explicit 
> about that.
>
> -- Christian Huitema
>
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>

---

From: Melinda Shore <[email-masked]>
Date: Thu, 9 Dec 2021 10:45:15 -0900

On 12/9/21 10:13 AM, Christian Huitema wrote:
> for centralization. 

I think that would actually weaken the draft.  The IETF really
can't do anything about the economics of centralization, nor
respond to that in a particularly meaningful way, and I'd argue
that the IETF is in absolutely no position to work with
those larger-scale decentralization technologies which are responsive
to the economic pressures driving centralization.  But, I do think
he's been successful at identifying limited protocol-related
centralization issues that can be considered in the design/
architecture of IETF products.  And that is, after all, the clear
goal of this document.

I agree that there's a place for the broader discussion but I don't
think it's here (i.e. in the IETF context I don't think it would do
much other than express the moral indignation you referenced).

Melinda

-- 
Melinda Shore
[email-masked]

Software longa hardware brevis

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 9 Dec 2021 19:50:52 +0000

Hiya,

On 09/12/2021 19:32, Eliot Lear wrote:
> I don't think we need to get anywhere near that crass,

Odd choice of words. I didn't see anything there I'd describe
as crass.

> Christian.  Quite 
> probably harming security.

At this point, IMO we'd benefit from more well-managed SMTP
services - far too high a percentage of mailboxes and
messages are run on fewer than a handful of services. I think
that's bad for the mail ecosystem. (And we're far far from
a zillion independently operated SMTP servers - I'd not be
surprised if it were <1M now.)

>  But maybe having – and this will amuse some 
> server. 

Not nobody. I do want to manage my own and do so for some
other mail accounts. That's made harder by e.g. opaque
practices in some of the mega mail receivers who feel big
enough to commonly send non-spam to /dev/null and never
explain at all.

Cheers,
S.

PS: I've only skimmed Mark's draft, so not sure what I
think of it yet.

> connecting via imap (or something else) to gmail/yahoo/hotmail

---

From: Christian Huitema <[email-masked]>
Date: Thu, 9 Dec 2021 12:01:40 -0800

> architecture of IETF products.  And that is, after all, the clear

Yes, the draft does that.
> much other than express the moral indignation you referenced).

My main concern is that if we do not address the broader economic issue, 
then we are only acting at the margin. On the other hand, yes, I am 
aware that there are strong limits to what the IETF as a body can do. 
But I can't help finding these limits very frustrating.

-- Christian Huitema

---

From: Geoff Huston <[email-masked]>
Date: Thu, 9 Dec 2021 20:19:52 +0000

> I'm not done yet (this is quite rough, handwave-y, and incomplete), but would be interested in feedback/issues/PRs.

The basic assumption in this draft is that the position we find ourselves in with the Internet has some kind of technical cause and any change to get us all out of this situation can be achieved by making different technology choices for future applications. Any student of economic history would at this stage be likely rolling on the floor laughing at such a preposterous assumption. The very reasons why the Internet was such a success and represented such an attractive vehicle for investment are of course tightly associated with notions of market positioning by the various actors, and the role of entrepreneurial stimulation and the supportive role of venture capital that were behind today’s business giants indicate the the signs of susceptibility of the Internet to comprehensive morket domination were clear by the early ‘90s. Billions of dollars (trillions?) of venture capital would not have been tipped into the Internet if the anticipated rate of return on this capital injection was negative, or even mere double or triple digits of percentage return. And the only way to achieve such returns lie in comprehensive market domination.

I like the quixotic notion in the abstract that centralisation in the Internet is something that is a future prospect, and that it can be avoided. I have to wonder how anyone could imagine that this centrality is not just a reality today but has been a dominant factor for over two decades now. Moreover, the comprehensive market domination by a few is the basic reason why Internet services are so cheap, so abundant and why they have permeated today’s societies so comprehensively. 

To try and get back to the draft, I have to observe that it's an odd draft containing some basic common sense about effective application design and some fully rocket-ship-to-andromena-scale unworldly notions, such as the concept that multi-stakeholderism is an effective counter to the basic inexorable disciplines of market forces. If you want to rail about where we are today you really should be bemoaning the deregulation of the telco industry that had its antecedents in the 1960’s in the US. We replaced the concept of sanctioned monopolies in this sector in the 1980’s and in their place we said that the user is in charge and they should be free to spend their money on the purchase of goods and service from a deregulated market. Adam Smith’s invisible hand would assure us all that everything would be Just Fine. It's not, but the problem is not related to the technology. It's not even slightly related to concepts of multi-stakeholderism. The issues we are facing here relate more closely to the earlier rise of the print barons in terms of social influence and power, the rise of television networks, and the network owner’s level of social influence and power.

The point I’m making here is that the concepts of technology design and the issues of market behaviours are largely orthogonal issues, and we should not kid ourselves in thinking that the Internet’s intrinsic architecture got us here (it did not) and that tweaking this architecture will get us out of here (it will not).

By all means let's look at the changing roles of our common infrastructure issues of naming, addressing, routing, security, services, distribution and transactions in this environment and the ways we can respond to these changing pressures in today’s Internet. But at the same time lets stop kidding ourselves that anything we may do will have the slightest impact on the situation of economies of scale and desire to maximise profits now and the future push market actors to aggregate and centralize.

Let's also think about the notion that the drop in direct costs for the Internet’s service to users has been the major, or even the only, factor that really matters. In the same way that the penny post in the United kingdom dropped the postal rate for a letter from a day’s working wages (2s3d) to a mere penney was completely transformational, the drop in the relative cost of the services we’ve built today is also totally transformational. The more substantive debate, which transcends all this wailing and gnashing of teeth over the size of these corporate entities that are driving this change today, is whether our social structures are robust enough to survive the onslaught of such fundamental transformational forces. I fear that like the recent examples we have had to endure in the area of national politics in many countries are already providing a clear (and extremely depressing) answer.

Geoff

---

From: Eliot Lear <[email-masked]>
Date: Thu, 9 Dec 2021 13:25:43 -0700

On 09.12.21 21:01, Christian Huitema wrote:
>>> I think Mark's draft could be improved by analyzing the economic 
>>> push for centralization. 
>>
Daniel Karrenberg and Tom Vest did that at RIPE some years ago for the 
European SP market.  Want to try it with social networking or 
streaming?  And now let's correlate those markets with encryption or 
intermediation.   I'll bet you a fancy drink the next time we see each 
other that encryption is positive to the HHI in both of those markets 
(in disagreement with what Mark writes), and that there is no 
correlation for intermediation.  And the positive correlation for 
encryption probably doesn't mean a lot, because... well, we've all seen 
the funny graphs.

But that means...

> My main concern is that if we do not address the broader economic 
> issue, then we are only acting at the margin. On the other hand, yes, 
> I am aware that there are strong limits to what the IETF as a body can 
> do. But I can't help finding these limits very frustrating.
>
... that, yes, you HAVE to do the economic and engineering analysis to 
understand what, if any, protocol choices really make any difference and 
still scale.  One can simply reinvent PGP and enjoy all the success that 
it's had.  Same with alternative social networks.  I only wish they 
could take off.  Beating the network effect is HARD.  Beating economies 
of scale is even HARDER.

Long and short- I agree with you, Christian, that at best this would be 
the tail wagging the dog.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 9 Dec 2021 13:29:23 -0700

Sorry, bad edit: see below:

On 09.12.21 21:25, Eliot Lear wrote:
> Daniel Karrenberg and Tom Vest did *an HHI analysis* at RIPE some 
> years ago for the European SP market.  Want to try it with social 
> networking or streaming?  And now let's correlate those markets with 
> encryption or intermediation.   I'll bet you a fancy drink the next 
> time we see each other that encryption is positive to the HHI in both 
> of those markets (in disagreement with what Mark writes), and that 
> there is no correlation for intermediation.  And the positive 
> correlation for encryption probably doesn't mean a lot, because... 
> well, we've all seen the funny graphs.
>
> But that means...
>
>>>
>> I am aware that there are strong limits to what the IETF as a body 
>> can do. But I can't help finding these limits very frustrating.
>>
> understand what, if any, protocol choices really make any difference 
> and still scale.  One can simply reinvent PGP and enjoy all the 
> success that it's had.  Same with alternative social networks.  I only 
> wish they could take off.  Beating the network effect is HARD.  
> Beating economies of scale is even HARDER.
>
> Long and short- I agree with you, Christian, that at best this would 
> be the tail wagging the dog.
>
> Eliot
>
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 9 Dec 2021 13:32:35 -0700

Hi Stephen,

On 09.12.21 20:50, Stephen Farrell wrote:
>> cyberprotection to occur in each of those intermediaries. Guess how 
>> much protocol work is need for that?  Zero.
>>
>> But it hasn't happened because nobody wants run/manage their own 
>> backend server. 
>
> other mail accounts. 

You, me, and a fewer other of us, sure. But again, as O'Dell said, the 
only think you have to worry about is scale, and we, my friend, are in 
the noise. *None* of us design for the techie because that is not where 
the money is.  Oh dear, economics again.

Eliot

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 9 Dec 2021 15:48:00 -0500

I only had two pages to make the point for a recent CoNEXT workshop, but a
related perspective is at https://arxiv.org/abs/2111.03785

My concern is not just the ineffectiveness, but possible distraction:
"Let's just do better protocol engineering and we don't have to worry about
the bigger picture." This is a version of the "let's encrypt all the
channels and that will solve the consumer privacy problems".

I didn't have the space to make that argument, but there is another factor:
Concentration is most pronounced for certain key consumer (and enterprise)
applications. At least for DNS and email (or CDNs), there are a handful of
reasonable, competitive choices and self-provisioning is still a
possibility, at least for larger entities.

For the three most popular non-gaming consumer applications beyond web and
email, i.e., shared documents/files (Box, Google Drive, ...), video
conferencing and social media, there are no good standards-based options
(we have bits and pieces, but nothing that could compete with the consumer
experience of Zoom or similar tools). I'm not counting WebRTC here as this
treats the host largely as a general-purpose programmable platform and
usually leads to indirect centralization.

In my area of multimedia collaboration, the last attempt at a
standards-based full-featured system was XCON, eons ago. It's unclear who
would be willing to do the work - as Geoff points out, the economic
incentives are all in the other direction.

Also, the complexity of our protocols has reached the point that most
protocol stacks now have only one or two dominant open-source (or any)
implementations, from DNS to MTAs to HTTP to browser engines. (According to
the data at https://powerdns.org/dns-camel/, you'd have to read 4,001 pages
of DNS specs across 238 RFCs, excluding historic ones, to implement a
full-featured DNS server.)

Henning

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 9 Dec 2021 21:56:02 +0100

Mark:

If a document like this as an RFC would have to have any standing, i think it
is important to ensure that is much more a community effort than the typical
technical informational document, where the document mostly reflects the authors
point of view with just some grudging changes from feedback.

To that end:

a) It would be great to find more authors and delegate responsiblity for chapters
   across multiple authors.

b) at an appropriate stage of the doc, start a questionaire for the IETF community (which
   TBD questions) to seek feedback from a broader part of the community than the
   normal review process (like i think Jay/LLC are quite successful with vetting 
   opinions of the community about LLC related questions).

Christian:

I would appreciate if an appropriately adjusted version of your thoughts would make
it into the document.

Other thoughts: 

a) Google services (as an exampe) are highly dsitributed/centraliced. They are just
in most countries so market dominating that they can be called (quasi) monopolies
(especially search, video). "centralized" is therefore not a good word to frame
the discussion.

b) what Christian left out talking about the political control of those global
services is that those services by default bring in the business, political, social
and moral values of the country from which they originate. They are the 21st century
version of what Hollywood was in the 20th century, but likely a lot more intrusive
- as we've seen in arab spring.

Some bigger countries may manage to create some regulation, but most countries
could never dare to regulate them unless complete withdrawal of the service was
an acceptable outcome. Critics of the USA might call this cultural imperialism by proxy.

E.g.: Find co-authors from Rusia, China and Arab countries to write that chapter 
about the politics if you really want to get a broader representation of the
challenges for the broader community. Or else be humble enough to state that
the document is only representing a very narry, US centric view of the subject matter.

Cheers
    Toerless

On Thu, Dec 09, 2021 at 11:13:24AM -0800, Christian Huitema wrote:
> I think Mark's draft could be improved by analyzing the economic push for
> centralization. Some of the centralization might happen due to random forces
> and weaknesses in the initial design, but lots of it result from conscious
> strategies pushed by investors. To put it briefly, investors reward 
> monopolies, because monopolies end up making way more profits than players
> in competitive markets. The naive entrepreneur who has a startup idea will
> be guided by investors towards being more realistic, and looking at
> strategies to build that startup into a dominant player. Those strategies
> largely sum up to building a monopoly.
> 
> entrepreneurs that they should go swim in uncontested territory, blue water,
> rather than where sharks are already feeding, red water. That's an euphemism
> for not trying to compete with existing monopolies. The "moat" metaphor
> explains entrepreneurs that they should protect their business through an
> unassailable moat, just like castles in medieval times. Suggested moat
> building strategies include amassing patents, cultivating network effects,
> and reaching scale quickly before competitors have a chance to grab the
> market. Of course, those strategies are not limited to startups. If a
> division of a large company wants to develop a new line of products, it will
> receive the same advice. The entrepreneurs who can convince investors of
> their potential for building a monopoly will be rewarded with large amount
> Historically, monopolies last a long time. Most fail only after decades of
> success engender complacency and bureaucracy, which would mean that we are
> stuck with centralization for decades. The exception would be monopolies
> dismantled by explicit political action, such as the movement leading to the
> Sherman Act, but that is somewhat outside the realm of standards.
> 
> Faced with that, our moral indignation and our push for virtuous standards
> is likely to fail. We won't get competition if nobody dares fight the
> existing monopolies, or if those who dare regularly get crushed. We won't
> get much standard activism if the engagement against monopolies concentrates
> in the political realm. But we can still try, of course. That probably means
> studying the strategies used to preserve monopolies, and setting up to
> explicitly counter them. Pushing technologies that are not blocked by
> patents, developing standards that break interoperability barriers. We
> should be explicit about that.
> 
> -- Christian Huitema
> 

-- 
---
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 9 Dec 2021 20:56:34 +0000

Hiya,

On 09/12/2021 20:32, Eliot Lear wrote:
> You, me, and a fewer other of us, sure.

Right. And we (as in IETF) ought ensure that remains
technically possible, to the extent we can. I'm not
at all saying that solves anything, but I do think we
ought consider providing technologies that can be
de-centralised is a duty we ought consider applying
to the work we do.

> But again, as O'Dell said, the 

I've neither agreed nor disagreed with anything said
in this thread about economics.

Cheers,
S.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 10 Dec 2021 14:44:34 +1100

Hi Geoff.

My initial reaction to your comments was to think that you hadn't read the draft, or had only skimmed beyond the first few paragraphs. In particular, you seem to be reading in some claims that I'm not attempting to make. 

After some reflection, I do think some adjustments to the abstract and introduction could help avoid that misreading; the draft has been written over a fairly long period of time, and has already gone through a number of adjustments and re-castings. The preliminaries probably haven't kept up with the direction it's gone in.

To be clear: I do not think that federation, multi-stakeholder administration, or distributed consensus are at all adequate to prevent or mitigate centralisation. 

We're now seeing claims that the IETF has a role (or even duty) to avoid, curtail, or prevent centralization in the protocols it publishes -- often, connected to dire warnings about the application of competition law. Often, those claims are more of the nature 'this changes the dynamics of my market and I lose out' then any actual competition issue. Regardless, we don't have good tools or even terminology to use when this comes up. We're also seeing claims that wonderful new technologies have attributes that will magically solve these problems (never mind that the many obvious shortcomings). One purpose I had for writing this draft is to ground those discussions more sensibly. 

I also think that there are broader opportunities and risks in this area. While architectural regulation (as per the IETF and similar) is very limited by nature in what it can do (or even encourage/discourage) regarding centralisation, legal regulation is very much on the way. If that regulation only engages with 'big tech' as a stakeholder representing technical interests, we shouldn't be surprised if the result looks a lot like big tech ossified into place with a few constraints layered on top. OTOH, the injection of a legal mandate into what was previously voluntary standards brings some very interesting possibilities -- and of course correspondingly new ways to fail spectacularly. This document doesn't directly address that aspect, but in my mind what it covers is foundational for it.

To these ends, I'm very happy to reduce the ambitions that you read into it. Expect a -01 soon.

Cheers,

> On 10 Dec 2021, at 7:19 am, Geoff Huston <[email-masked]> wrote:
> 
>>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 10 Dec 2021 14:44:53 +1100

Hi Christian and Melinda,

> On 10 Dec 2021, at 7:01 am, Christian Huitema <[email-masked]> wrote:
> 
> 
>>> I think Mark's draft could be improved by analyzing the economic push for centralization. 
>> 
>> respond to that in a particularly meaningful way

I agree, and we don't have the relevant expertise or authority. So while I appreciate Christian's viewpoint here, I'd really be looking for (at most) a reference or two and accompanying (brief) text, rather than a dramatic expansion of scope.

>> and I'd argue
>> to the economic pressures driving centralization.

I'd be interested in discussing that more. Don't necessarily disagree, but it seems like there might be something interesting here.

>> But, I do think
> My main concern is that if we do not address the broader economic issue, then we are only acting at the margin. On the other hand, yes, I am aware that there are strong limits to what the IETF as a body can do. But I can't help finding these limits very frustrating.

*We* don't have to do everything. The IETF has very limited authority, mostly centred on producing technical specifications that work. Yes, that's frustrating.

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Dec 2021 17:04:02 +1300

> I agree, and we don't have the relevant expertise or authority. So while I appreciate Christian's viewpoint here, I'd really be looking for (at most) a reference or two and accompanying (brief) tex…

Perhaps:
https://blog.apnic.net/wp-content/uploads/2021/12/MKGRA669-Report-for-APNIC-LACNIC-V3.pdf

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Dec 2021 06:58:40 +0100

> full-featured DNS server.)

Very interesting point as well.

- Of course this is something we as IETF could do something about,
  from coalescing/simplifying documentation (RFCs) to trying to 
  reduce complexity.

- Likewise the interesting question is how much diversity in open source
  implementations we think we need for a resilient Internet.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Dec 2021 07:20:21 +0100

On Thu, Dec 09, 2021 at 01:25:43PM -0700, Eliot Lear wrote:
> still scale.

Analysis is IMHO too strong. But documenting the economic
resons / use-cases / opportunities / challenges as they relate to
the protocols would be quite helpful. All the stuff many of us here
do know but we never documented.

>  One can simply reinvent PGP and enjoy all the success that
> it's had.  Same with alternative social networks.  I only wish they could
> take off.  Beating the network effect is HARD.  Beating economies of scale
> is even HARDER.
> 
> Long and short- I agree with you, Christian, that at best this would be the
> tail wagging the dog.

Documenting problems is also useful, even if we can not paint a path to
better solutions for all of them.

When it comes to defining new "protocols" to solve problems better than we do
now, i think its all about stakeholders: We have always been reactively
creating standards driven by the stakeholders who think they could benefit
from the standards. But i don't think we reach all desirable stakeholders.

Example: Regulators. And of course immediate reaction: Oh, you can not
ever do something FOR a regulator, only AGAINST. But i can see examples, where such
regulation could well go along with IETF values (such as the Internet is
for end users). For example standard export import data formats for your
life's data on a social network, so you're not locked into one products prison.
Such data format standards could be required in countries by regulators.
But right now, IETF only has representation of those who want to keep up
those prison walls and will argue forever that such data
formats would be completely im{possible,practical,...}.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Christian Huitema <[email-masked]>
Date: Thu, 9 Dec 2021 23:03:26 -0800

> formats would be completely im{possible,practical,...}.

That particular example is not directly tied to regulation. One could 
see a group of cooperating social networks asking to normalize something 
like that. That's not fundamentally different from the efforts than 
produced Internet Calendaring, for example. Is there any evidence that 
this could not be done in the IETF?

-- Christian Huitema

---

From: Eliot Lear <[email-masked]>
Date: Fri, 10 Dec 2021 08:45:04 +0100

My point is that asking about correlation and causation in these cases 
is a better starting than an opinion.  But as long as we're throwing out 
opinions, here's mine (I know you were dying to have it):

The #1 challenge for this decade *won't* be security alone and it 
*won't* be market concentration on its own, but it *will* be 
resilience.  We built All of This, but failures with, as one of my 
colleagues who can out him/herself if he wants said, "a large blast 
radius" are becoming more conspicuous if not more common.

Want to get scared?  Go review that phenomenal ANRP/IMC paper by Aqsa 
Kashaf (Analyzing Third Party Service Dependencies in Modern Web 
Services: Have We Learned from the Mirai-Dyn Incident?[1]). That's 
something that perhaps some standardization efforts could help.

Now it so happens that economies of scale have led to a large 
concentration of risk into certain firms.  There is some opportunity for 
standardization to avoid some of that risk, and that the incentives 
*might* point in the right direction, but it will depend on the service, 
as perhaps it should.  I refuse to be too upset about a gaming server 
going down, but I'm going to be quite put off if first responder systems 
fail.

But most of that work isn't at the IETF, although the work of Claise et 
al goes there[2]. It is happening at OWASP[3], the Linux Foundation[4], 
and (shutter) ISO.  A shout out in particular to Patrick Dwyer for his 
work on CycloneDX in being able to build service dependency trees, but 
we are in early days.  How that percolates through the supply chain is 
also being considered in various ways such as openchain[5] and digital 
bills of materials (DBOMs).[6]  FWIW, there's good reason for the Linux 
Foundation to take lead in a lot of this, since there is a lot of tool 
chain integration needed, right down to compilers.

If the formats exist, then the next question is why aren't they heavily 
used? Part of it is tool immaturity, and part of it is a lack of demand 
for services to expose their dependencies.  That is indeed where 
regulation may come to play, as it is doing so in the US (see §4 of the 
May 12th Executive Order)[7].  The presumption in all of this is that if 
there is at least transparency, then we have the opportunity to do 
something about weak links and service dependencies.  Whether we act on 
that will very much depend on the specific service.  Will that limit 
concentration?  Perhaps, but that would be merely a happy side effect, 
if it happens at all. But IMHO there clearly is a role of regulators to 
play when it comes to the things upon which we as society rely.  And 
Mark's not wrong about this: when we talk about regulation, big players 
tend to win out.

Eliot

[1] https://www.andrew.cmu.edu/user/akashaf/assets/files/Webdep.pdf
[2] draft-ietf-opsawg-service-assurance-architecture-02.txt
[3] https://cyclonedx.org
[4] https://spdx.org
[5] https://www.openchainproject.org/
[6] https://dbom-project.readthedocs.io/en/latest/
[7] 
https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Dec 2021 09:17:16 +0100

There is also the recurring evidence that technologies like ACP (RFC8994)
could help to shorten/overcome several of the big outages in big players.
The RFC itself has one reference to a case FCC investigated because it
affected 911 (and hence also incurrect significant penalties), but cases
 such as the recent Facebook cases did not affect regulated servces
and where such not independently investigated. From what i could figure
out from public information it did seem very similar though and possible
to be helped by ACP.

At the high likelyhood of annoying readers here with my repeated
mentioning of regulators not all being evil, i do like FCC investigating
service failures (and fining them), and maybe that should not be constrained
to 911 services. Yes, the best (lousy) effort architecture of todays
network (Internet plus OTT) works pretty well also through corona. But
not good enough for criticial infrastructure services. And there is a big
risk for critical infrastructure services to not have any affordable alternative
to this BE Internet/OTT's. As could be seen from e.g.: Fire Departments in California and
how they coud communicate with the public (before Comcast switched them
off for exceeding their monthly service volume).

Too bad that StevenF's attempt to create some moment around resilience
never took off.

Cheers
    Toerless

On Fri, Dec 10, 2021 at 08:45:04AM +0100, Eliot Lear wrote:
> My point is that asking about correlation and causation in these cases is a
> better starting than an opinion.  But as long as we're throwing out
> The #1 challenge for this decade *won't* be security alone and it *won't* be
> market concentration on its own, but it *will* be resilience.  We built All
> of This, but failures with, as one of my colleagues who can out him/herself
> if he wants said, "a large blast radius" are becoming more conspicuous if
> not more common.
> 
> Want to get scared?  Go review that phenomenal ANRP/IMC paper by Aqsa Kashaf
> (Analyzing Third Party Service Dependencies in Modern Web Services: Have We
> Learned from the Mirai-Dyn Incident?[1]). That's something that perhaps some
> standardization efforts could help.
> 
> Now it so happens that economies of scale have led to a large concentration
> of risk into certain firms.  There is some opportunity for standardization
> to avoid some of that risk, and that the incentives *might* point in the
> right direction, but it will depend on the service, as perhaps it should.  I
> refuse to be too upset about a gaming server going down, but I'm going to be
> quite put off if first responder systems fail.
> 
> But most of that work isn't at the IETF, although the work of Claise et al
> goes there[2]. It is happening at OWASP[3], the Linux Foundation[4], and
> (shutter) ISO.  A shout out in particular to Patrick Dwyer for his work on
> CycloneDX in being able to build service dependency trees, but we are in
> early days.  How that percolates through the supply chain is also being
> considered in various ways such as openchain[5] and digital bills of
> materials (DBOMs).[6]  FWIW, there's good reason for the Linux Foundation to
> take lead in a lot of this, since there is a lot of tool chain integration
> needed, right down to compilers.
> 
> used? Part of it is tool immaturity, and part of it is a lack of demand for
> services to expose their dependencies.  That is indeed where regulation may
> come to play, as it is doing so in the US (see §4 of the May 12th Executive
> Order)[7].  The presumption in all of this is that if there is at least
> transparency, then we have the opportunity to do something about weak links
> and service dependencies.  Whether we act on that will very much depend on
> the specific service.  Will that limit concentration?  Perhaps, but that
> would be merely a happy side effect, if it happens at all. But IMHO there
> clearly is a role of regulators to play when it comes to the things upon
> which we as society rely.  And Mark's not wrong about this: when we talk
> about regulation, big players tend to win out.
> 
> Eliot
> 
> [7] https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity
> 

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 10 Dec 2021 09:27:30 +0100

On Thu, Dec 09, 2021 at 11:03:26PM -0800, Christian Huitema wrote:
> That particular example is not directly tied to regulation. One could see a
> group of cooperating social networks asking to normalize something like
> that.

Yes, could be, but AFAIK has not happened so far, but enforcement through
regulation is another possible way for this to happen, and in that case
we likely would not be in the picture because regulators would most likely
not know how to engage with us.

A current similar example (the way i see it) is this here:

https://www.eff.org/deeplinks/2021/11/eu-parliament-takes-first-step-towards-fair-and-interoperable-market

Have to read up more on it, but with my usual paranoia, i am sure the
players will find a way to make the price of entry high enough to
protect against new challengers.

> That's not fundamentally different from the efforts than produced
> Internet Calendaring, for example. Is there any evidence that this could not
> be done in the IETF?

Of course. My point was just about the stakeholders we have vs. the ones
we may want to retink of being more welcoming too. A lot of the stakeholders
we do have have evolved into business models that are not necessarily
very supportive of the IETF values, still we do built standards for them.
Likewise, other groups such as regulators may be evolving from stances
that where contrary to IETF values to also become proponents of IETF
values, especially in areas such as end-users rights.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Dirk Trossen <[email-masked]>
Date: Fri, 10 Dec 2021 08:53:44 +0000

Eliot,

Your resilience point is going in the right direction IMO but it’s still too ‘systems’ oriented for me. I would argue that much of the concentration (with all its problems of resilience in the light of recent outages) we are seeing today comes down to ‘choice’ and the possible lack of it.

Centralization may play a factor in limiting choice. But conversely, centralization of protocol functions does not necessarily impact the choice issue per se. Let’s take the example of the email system (e.g., IMAP). It’s centralized by design for the end user (i.e., needing to use a specific IMAP server), while being decentralized in the federation of IMAP servers. By design, we can easily have hundreds of millions of IMAP servers, even down to families and alike, despite its centralized design in the B2C interface. It’s (relatively) easy to configure in mail clients so all is well, isn’t it?

However, what we DO have is a concentration of email to three main providers – why’s that? It’s because the point of choice has been concentrated by those three players without imposing appropriate control over this choice (which is mainly a regulation issue). This limitation happens when signing up to Android, iOS or Windows, since most people will go along with the typical linkage to the Google/Apple/Microsoft email system. So concentration here is not driven by the protocol features (despite its centralized design in the B2C interface) but by the realization of choice in that interface’s realization with the concentration point being the selection of the IMAP server. So maybe it’s not about centralization really but about possible points of concentration, e.g., by limiting choices in selecting providers of interfaces in a design. Another well-known example is search by setting the default engine, either through linkage of browser and search company or paying a hefty price for being selected default engine; albeit search being based on an inherently distributed, i.e., the web, architecture.

Why is this important? I would argue that undue market powers come into play when such choice limitation at points of concentration happens. Regulation may counter this but the nature of this concentration to happen makes regulation entirely reactive, often lagging years behind well-observed concentration of market power. What I do believe the technical community (in the IETF) can do is outline those possible points of concentrations in protocol specifications, providing at least the possibility of proactive regulation that could aim at avoiding any such concentration to happen (i.e., the IETF provides support to counter undue market powers but is not the enforcing entity).

Maybe we need a mandatory “choice considerations” section alongside the “security considerations” in future drafts?

Best,

Dirk

From: Architecture-discuss [mailto:[email-masked]] On Behalf Of Eliot Lear
Sent: 10 December 2021 08:45
To: Christian Huitema <[email-masked]>; Toerless Eckert <[email-masked]>
Cc: Patrick Dwyer <[email-masked]>; [email-masked]; Benoit <[email-masked]>; [email-masked]
Subject: [arch-d] Let's talk about something else: resiliency (Re: Fwd: New Version Notification for draft-nottingham-avoiding-internet-centralization-00.txt)

My point is that asking about correlation and causation in these cases is a better starting than an opinion.  But as long as we're throwing out opinions, here's mine (I know you were dying to have it):

The #1 challenge for this decade won't be security alone and it won't be market concentration on its own, but it will be resilience.  We built All of This, but failures with, as one of my colleagues who can out him/herself if he wants said, "a large blast radius" are becoming more conspicuous if not more common.

Want to get scared?  Go review that phenomenal ANRP/IMC paper by Aqsa Kashaf (Analyzing Third Party Service Dependencies in Modern Web Services: Have We Learned from the Mirai-Dyn Incident?[1]).  That's something that perhaps some standardization efforts could help.

Now it so happens that economies of scale have led to a large concentration of risk into certain firms.  There is some opportunity for standardization to avoid some of that risk, and that the incentives might point in the right direction, but it will depend on the service, as perhaps it should.  I refuse to be too upset about a gaming server going down, but I'm going to be quite put off if first responder systems fail.

But most of that work isn't at the IETF, although the work of Claise et al goes there[2]. It is happening at OWASP[3], the Linux Foundation[4], and (shutter) ISO.  A shout out in particular to Patrick Dwyer for his work on CycloneDX in being able to build service dependency trees, but we are in early days.  How that percolates through the supply chain is also being considered in various ways such as openchain[5] and digital bills of materials (DBOMs).[6]  FWIW, there's good reason for the Linux Foundation to take lead in a lot of this, since there is a lot of tool chain integration needed, right down to compilers.

If the formats exist, then the next question is why aren't they heavily used? Part of it is tool immaturity, and part of it is a lack of demand for services to expose their dependencies.  That is indeed where regulation may come to play, as it is doing so in the US (see §4 of the May 12th Executive Order)[7].  The presumption in all of this is that if there is at least transparency, then we have the opportunity to do something about weak links and service dependencies.  Whether we act on that will very much depend on the specific service.  Will that limit concentration?  Perhaps, but that would be merely a happy side effect, if it happens at all.  But IMHO there clearly is a role of regulators to play when it comes to the things upon which we as society rely.  And Mark's not wrong about this: when we talk about regulation, big players tend to win out.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Fri, 10 Dec 2021 10:13:49 +0100

Hi Dirk,

Just on this for now...

On 10.12.21 09:53, Dirk Trossen wrote:
>
> Centralization may play a factor in limiting choice. But conversely, 
> centralization of protocol functions does not necessarily impact the 
> choice issue per se. Let’s take the example of the email system (e.g., 
> IMAP). It’s centralized by design for the end user (i.e., needing to 
> use a specific IMAP server), while being decentralized in the 
> federation of IMAP servers. By design, we can easily have hundreds of 
> millions of IMAP servers, even down to families and alike, despite its 
> centralized design in the B2C interface. It’s (relatively) easy to 
> configure in mail clients so all is well, isn’t it?
>
And even if we do have millions of IMAP servers, they would likely be 
taken from 2 or 3 implementations.  That's a point that Henning made 
that shouldn't get lost.

Eliot

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 10 Dec 2021 11:17:17 -0500

One of the classic regulatory tools is transparency. (As an example, I
worked on the FCC Measuring Broadband America project, measuring speed and
reliability of consumer ISPs in the US.)

We will likely see increased demands for transparency across the stack,
from infrastructure to key applications. Standards, both protocols/formats
to get that data and even well-defined metrics, are extremely helpful there
- and mostly lacking. The IETF LMAP effort is one outcome, albeit not
exactly the most successful one.

The second common thread is portability, i.e., the ease of moving from one
service to another. Email is a classical negative example - it's easy, in
many countries, to move your phone service to another carrier, while still
retaining the same phone number. (This usually required a decade+ of
regulatory fights against the incumbents, so it's easy only in hindsight.)
One of the reasons for email dominance is the fly trap effect - once you
have signed up for a gmail or AOL address, switching becomes extremely
painful. It's not just that you have to get all your friends to switch, but
you also have to update the user ID for many services, as you otherwise
likely lose your ability to recover passwords. This was a fundamental
design flaw in email - not unreasonable during a period of time when email
addresses were generally institutional or corporate, but
concentration-promoting for consumers. There's a lesson here.

Let me repeat something else: We focus on core protocols that are now 30+
years old. All good - but I suspect that the concentration in the email
market is not top-of-mind for consumers or regulators at the moment. The
IETF simply does not offer* functionally competitive *protocols for any
application beyond web, email and carrier two-party voice and text. No
video conferencing, no social media, no file/document sharing.

Henning

On Fri, Dec 10, 2021 at 1:20 AM Toerless Eckert <[email-masked]> wrote:

> the

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Dec 2021 08:59:33 +1300

On 10-Dec-21 20:45, Eliot Lear wrote:
> My point is that asking about correlation and causation in these cases is a better starting than an opinion.  But as long as we're throwing 
out opinions, here's mine (I know you were dying to have it):
> 
> The #1 challenge for this decade *won't* be security alone and it *won't* be market concentration on its own, but it *will* be resilience.  
We built All of This, but failures with, as one of my colleagues who can out him/herself if he wants said, "a large blast radius" are becoming more conspicuous if not more common.
> Now it so happens that economies of scale have led to a large concentration of risk into certain firms.  There is some opportunity for standardization to avoid some of that risk, and that the incentives *might* point in the right direction, but it will depend on the service, as perhaps it should.  I refuse to be too upset about a gaming server going down, but I'm going to be quite put off if first responder systems fail.
> 
al goes there[2].

To a very large extent, the ANIMA work is aimed at resilience, and provides a general framework for resilience. From a superficial glance at draft-ietf-opsawg-service-assurance-architecture, I can't see any reason why it couldn't be built on top of ANIMA, for example.
(ANIMA can transport YANG if needed, of course.)

Robustness is specifically addressed in draft-ietf-anima-asa-guidelines (currently in IETF Last Call).

     Brian

  It is happening at OWASP[3], the Linux Foundation[4], and (shutter) ISO.  A shout out in particular to Patrick Dwyer for his work on CycloneDX in being able to build service dependency trees, but we are in early days.  How that percolates through the supply chain is also being considered in various ways such as openchain[5] and digital bills of materials (DBOMs).[6]  FWIW, there's good reason for the Linux Foundation to take lead in a lot of this, since there is a lot of tool chain integration needed, right down to compilers.
> If the formats exist, then the next question is why aren't they heavily 
used? Part of it is tool immaturity, and part of it is a lack of demand for services to expose their dependencies.  That is indeed where regulation may come to play, as it is doing so in the US (see §4 of the May 12th Executive Order)[7].  The presumption in all of this is that if there is at least transparency, then we have the opportunity to do something about weak links and service dependencies.  Whether we act on that will very much depend on the specific service.  Will that limit concentration?  Perhaps, but that would be merely a happy side effect, if it happens at all. But IMHO there clearly is a role of regulators to play when it comes to the things upon which we as society rely.  
And Mark's not wrong about this: when we talk about regulation, big players tend to win out.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 10 Dec 2021 22:05:06 -0500

On Fri, Dec 10, 2021 at 11:18 AM Henning Schulzrinne
<[email-masked]> wrote:
>
> Let me repeat something else: We focus on core protocols that are now 30+ years old. All good - but I suspect that the concentration in the email market is not top-of-mind for consumers or regulators at the moment. The IETF simply does not offer functionally competitive protocols for any application beyond web, email and carrier two-party voice and text. No video conferencing, no social media, no file/document sharing.

I think this conflates cause and effect. People come to the IETF
because they need open standards. They avoid the IETF when they do
not. for one reason or another. The economics that make federalization
vs. centralization or a single instance of a service aren't the result
of IETF decisions. There's also an element of speed: prototyping your
own client and server lets you introduce features quickly, without
worries about third party adoption or breaking the spec. The economics
of open protocol client development have dramatically changed with the
decline of packaged software. The lacunae in what the IETF has
standarized results from those effects.

Sincerely,
Watson

--
Astra mortemque praestare gradatim

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 15 Dec 2021 16:23:20 +0100 (CET)

Apologies for being late to this very important discussion :)

> Il 09/12/2021 21:19 Geoff Huston <[email-masked]> ha scritto:
> 

I concur that it is at least arguable to which extent the Internet architecture got us here.  Still, there are decisions and stances that the IETF has taken that do contribute to the centralization of the Internet.  The best example: the coordinated push towards ubiquitous encryption that the IETF has been making does change the points of control over the Internet.

There are compelling reasons in favour of encryption and I am not at all suggesting that we should keep stuff flowing around in clear.  However, encrypting traffic in the current app-to-cloud-server environment, in which the application maker controls both ends of the connection and keeps everything within its own closed-source walled garden, significantly centralizes power.  It deprives the user's local jurisdiction of the practical ability to enforce any rules it might want to impose over tech companies, as these companies may operate out of jurisdiction and the government has no way to require ISPs to make their services unreachable if they are deemed incompliant with local legislation.  It also deprives the end-users of the possibility of controlling the traffic that client applications are transmitting, or entrusting a third party to do so on their behalf. 

By removing intermediaries from communications, and empowering tech companies against governments and sometimes even against end-users themselves, the IETF makes it practically harder, if not impossible, to revert the trend towards deregulation that you are identifying as the root cause of the trend towards centralization.

Now, as Mark says:

> Il 10/12/2021 04:44 Mark Nottingham <[email-masked]> ha scritto:
> 
> We're now seeing claims that the IETF has a role (or even duty) to avoid, curtail, or prevent centralization in the protocols it publishes -- often, connected to dire warnings about the application of competition law. Often, those claims are more of the nature 'this changes the dynamics of my market and I lose out' then any actual competition issue. 

Well, if companies with a dominant position in a neighbouring market write a new protocol, get it standardized at the IETF and deploy it to the effect that they capture a market that wasn't previously theirs, this *is* a competition issue.  It is indeed arguable how much the IETF should be held responsible for that, i.e. whether accepting to standardize the new protocol implies accepting being a part of potentially anticompetitive behaviour, also considering that protocols can be deployed by dominant parties even without having been standardized at the IETF.  If the new protocol is part of an explicit effort that the IETF has embraced, such as the quest for encryption, it is harder to claim that the IETF is not an active party to the plan, or at least the place where the plan is pursued, which might discharge the IETF from legal responsibilities but not from ethical and political ones.  Possibly, documents like yours could also be a way to discharge the IETF of part of the responsibilities (or the opposite, depending on the content of the document).

On a different point:

> I also think that there are broader opportunities and risks in this area. While architectural regulation (as per the IETF and similar) is very limited by nature in what it can do (or even encourage/discourage) regarding centralisation, legal regulation is very much on the way. If that regulation only engages with 'big tech' as a stakeholder representing technical interests, we shouldn't be surprised if the result looks a lot like big tech ossified into place with a few constraints layered on top.

We are having this schizophrenic discussion in the EU, where part of the upcoming provisions are meant to create more competition while another part is meant to regulate the current dominant platforms and crystallize their role.  Also, the debate on "big tech != Internet private sector" is ongoing in several other places, like the U.N. IGF, where concerns among civil society groups about this ossification are also very strong.  However, the only way to address this concern is to have more non-big-tech private sector get involved and speak up, both in SDOs and in policymaking venues.

This is one of the known limits of multi-stakeholderism: if not all stakeholders show up, the results are easily captured by private interests; and "having an open door" is not enough to confer legitimacy, especially in front of constituencies with clear collective action problems, like individual end-users.  But hey, this is the discussion we had at ICANN twenty years ago :)

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 15 Dec 2021 16:36:04 +0100 (CET)

> Il 10/12/2021 10:13 Eliot Lear <[email-masked]> ha scritto:
> 
> 
> 
> Hi Dirk,
> 
> Just on this for now...
> 
> And even if we do have millions of IMAP servers, they would likely be taken from 2 or 3 implementations.  That's a point that Henning made that shouldn't get lost.
> 
It is indeed an important point, but IMHO you should also consider whether the 2-3 implementations are open source or not.

If they are closed, you have a significant resilience issue and also a potential centralization issue, which may become a real centralization issue at any time without notice, whenever one of the owners of the software realizes that they can use their position to do something that suits them but not the user community.

If they are open, you still have the resilience issue but it is somewhat smaller, as many more people will be able to identify bugs or security issues and even to fix them before they become a problem; and the centralization issue almost disappears, because any disagreement on the future direction of the code or any attempt to use the code as a control point for other purposes may be countered by forking the project. True, forking still requires adequate know-how and may require a lot of resources if the project is big and complex, so you should evaluate its actual feasibility case by case to assess the risk; but if this countermeasure worked for an office suite, it can work for almost everything.

(Disclaimer: my employer is the maker of the most widely used of those 2-3 IMAP server implementations :-) )

(Also - for those who were wondering - the last OpenEmailSurvey http://openemailsurvey.org/ scanned around half of the Internet and found almost four million IMAP servers, of which 77% run Dovecot)

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Olaf Kolkman <[email-masked]>
Date: Fri, 17 Dec 2021 16:10:23 +0100

On 09.12.21 21:25, Eliot Lear wrote:
>> years ago for the European SP market. 

Talking about the Herfindahl-Hirschman Index, my colleagues have 
recently launched [a 
dashboard](https://pulse.internetsociety.org/centralization) that might 
be of interest in this discussion. It looks at centralisation indicators 
for Data Centers, DNS servers, Top Level Domains, CDNs, SSL Certificates 
and Web Hosting. See the tabs on the pages for methodology and such.

Best,

—Olaf

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Olaf M. Kolkman
This mail is  on personal title.
Tweets as: @kolkman
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 20 Dec 2021 16:36:21 +0100 (CET)

> Il 17/12/2021 16:10 Olaf Kolkman <[email-masked]> ha scritto:
> 
> 
> Talking about the Herfindahl-Hirschman Index, my colleagues have recently launched a dashboard https://pulse.internetsociety.org/centralization that might be of interest in this discussion. It looks at centralisation indicators for Data Centers, DNS servers, Top Level Domains, CDNs, SSL Certificates and Web Hosting. See the tabs on the pages for methodology and such.
> 
Thanks for the link. I found it interesting to see that the grouping with higher Gini values is neither "all" nor "top 1'000" but "top 10'000". Maybe I am over-interpreting this, but it could be that the very big players can escape concentration by deploying and managing their own big scale infrastructure, and the very small players can escape concentration by deploying and managing their own very small scale (typically open source) infrastructure, but the middle layer is where the efficiency of scale of going with a big dominant player is higher.

--

---

From: Dirk Trossen <[email-masked]>
Date: Tue, 21 Dec 2021 17:00:35 +0000

Hi Eliot,

Apologies for picking this up so late.

I don’t see the relation between having say 3 implementation choices and the choices for the servers I may be talking to. It’s the latter that we have seen restricted and which has led to a centralization in the email market. While I can understand that complexity of protocols may ultimately limit implementation choices, the number of such protocol implementations is irrelevant here for the choice of server/provider.

Now that choice of provider is limited elsewhere, which also Geoff points out in his material, namely through restricting choice at the level of OS (and their onboarding procedures). The same goes for search, web browser, etc. For good reason are regulatory bodies trying to address this issue albeit often too slow IMO.

My point of the proposed ‘choice considerations’ in protocol design and specification is to study and point out those possible restrictions of choice that may lead to centralization of some kind.

Dirk

From: Eliot Lear [mailto:[email-masked]]
Sent: 10 December 2021 10:14
To: Dirk Trossen <[email-masked]>; Christian Huitema <[email-masked]>; Toerless Eckert <[email-masked]>
Cc: Patrick Dwyer <[email-masked]>; [email-masked]
Subject: Re: [arch-d] Let's talk about something else: resiliency (Re: Fwd: New Version Notification for draft-nottingham-avoiding-internet-centralization-00.txt)

Hi Dirk,

Just on this for now...

Eliot

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Thu, 23 Dec 2021 00:02:27 +0700

Dear Eliot &
Architecture-discuss,

"Oikos":

"Internet", "environment", "architecture", "ecology", "economy" ...

"... the ancient notion of economy in the sense of managing a household,
derived
from the Greek oikonomia (“householding”). They applied this notion to the
state as the household of the ruler, and thus their policies became known
as
“political economy.” This term remained in use until the twentieth century,
when
it was replaced by the modern term “economics*1.”

"Ecology, from the Greek oikos (“household”), is the study of the “Earth
Household.” More precisely, it is the scientific study of the relationships
between the members of the Earth Household – plants, animals, and
microorganisms – and their natural environment, living and nonliving"2.

If the dictionary works for such an Internet (land)scape and an Internet
evSolution...?

NOTE:
*1
F.Capra & P.L. Luisi, "The System View" 3.1.4 "The Emergence of Economics"

https://www.pdfdrive.com/the-systems-view-of-life-a-unifying-vision-e195169892.html

*2
( Ibid., 16.1. "The Science of Ecology")

Regard,
Guntur Wiseno Putra

Pada Jumat, 10 Desember 2021, Eliot Lear <[email-masked]> menulis:

> only think you have to worry about is scale, and we, my friend, are in the
> noise.  *None* of us design for the techie because that is not where the
> money is.  Oh dear, economics again.
>
> Eliot
>

---

From: Guntur Wiseno Putra <[email-masked]>
Date: Sun, 26 Dec 2021 09:19:13 +0700

Dear Eliot &
Architecture-discuss,

"Economy of Scale" mentioned especially in the 2019 ISOC Report as a key
feature of current Internet consolidation "Interoperability as a Function"
of Scale (Ch. 6. "Takeaways and Observations"). (The term
"interoperability" reminds us about T. Berners-Lee said about the World
Wide Web specification as an interoperability of language, of softwares
working by the supports of hardwares.)*1

https://future.internetsociety.org/2019/wp-content/uploads/sites/2/2019/04/
InternetSociety-GlobalInternetReport-ConsolidationintheInternetEconomy.pdf

Yet there is "Total Services Environment" in the same chapter "Takeaways
and Observations" of the report*2

To the matters, such an "analytics of resemblances" for "Internet" and
"environment" may work for an Internet (land)scape" and an "Internet
evSolution"*3: I mean there is references closely related yet there are
others supposedly by one or other ways*4:

3 Scale as a Force of Deconstruction
Timothy Clark 81
Part II: Ecologies

4 The Posthuman Promise of the Earth
Philippe Lynes 101
(Here is an elaboration on "economy" & ecology)

6 Ecology as Event
Michael Marder
(Here is an elaboration on "economy" & ecology)

NOTES:
*1
https://future.internetsociety.org/2019/wp-content/uploads/sites/2/2019/04/
InternetSociety-GlobalInternetReport-ConsolidationintheInternetEconomy.pdf

https://w3.org/DesignIssues/Stack.html

*2
Op.Cit.

*3
https://mailarchive.ietf.org/arch/msg/architecture-discuss/
bMrv6HvFMyngtKX9V10Ep0Ye3LY/

*4
https://www.pdfdrive.com/eco-deconstruction-derrida-and-envi
ronmental-philosophy-e185901108.html

Regard,
Guntur Wiseno Putra

Pada Kamis, 23 Desember 2021, Guntur Wiseno Putra <[email-masked]>
menulis:

> “political economy.” This term remained in use until the twentieth
> century, when