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

[Henning Schulzrinne <[e-mail]>]

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 <[e-mail]> wrote:

> On Thu, Dec 09, 2021 at 01:25:43PM -0700, Eliot Lear wrote:
> > ... 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.
>
> 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
>
> > Eliot
> >
>
>
>
>
>
>
> > _______________________________________________
> > Architecture-discuss mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/architecture-discuss
>
>
> --
> ---
> [e-mail]
>
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>