Subject: [hrpc] re market forces & the Internet design process

From: Sandra Braman <[email-masked]>
Date: Mon, 5 Apr 2021 15:19:38 -0500

Given this thread, this might be a good time for people interested in the
question to review David D. Clark's argument in *Designing an Internet* (MIT
Press, 2018) re relationships between the Internet design process and
market-related issues.

Sandra Braman

On Mon, Apr 5, 2021 at 2:00 PM <[email-masked]> wrote:

> Send hrpc mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
> https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/hrpc__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CSbLfQ0VU$
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of hrpc digest..."
> Today's Topics:
>
>    1. Re: [[email-masked]: RFC 8980 on Report from the
>       IAB Workshop on Design Expectations vs. Deployment Reality in
>       Protocol Development] (Niels ten Oever)
>    2. Re: [[email-masked]: RFC 8980 on Report from the
>       IAB Workshop on Design Expectations vs. Deployment Reality in
>       Protocol Development] (Vittorio Bertola)
>    3. Re: [[email-masked]: RFC 8980 on Report from the
>       IAB Workshop on Design Expectations vs. Deployment Reality in
>       Protocol Development] (Stephane Bortzmeyer)
>    4. Re: [[email-masked]: RFC 8980 on Report from the
>       IAB Workshop on Design Expectations vs. Deployment Reality in
>       Protocol Development] (Stephane Bortzmeyer)
>    5. Re: [[email-masked]: RFC 8980 on Report from the
>       IAB Workshop on Design Expectations vs. Deployment Reality in
>       Protocol Development] (Stephane Bortzmeyer)
>
>
>
> ---------- Forwarded message ----------
> From: Niels ten Oever <[email-masked]>
> To: [email-masked]
> Cc:
> Bcc:
> Date: Mon, 5 Apr 2021 09:39:02 +0200
> Subject: Re: [hrpc] [[email-masked]: RFC 8980 on Report from
> the IAB Workshop on Design Expectations vs. Deployment Reality in Protocol
> Development]
>
>
> On 04-04-2021 14:21, Corinne Cath wrote:
> << snip >>
> > The report indicated both that "the protocol designers cannot affect
> market forces"
>
> This is quite interesting, especially taking into account that the IETF is
> mostly made up of people working for transnational corporations that
> concretely _are_ these market forces.
>
> Market forces are also somehow described as forces of nature that no one
> can predict or act against, which is also somewhat curious.
>
> Or perhaps it is a statement of believe, that the IETF is there to serve
> and facilitate the market? Which I think is not the case either because
> standards per definition exist to intervene in markets (by lowering costs
> and barrier of entry etc).
>
> Best,
>
> Niels
>
> >
> >
> >
> >
> >
> >
> > On Sat, Feb 20, 2021 at 10:04 AM Stephane Bortzmeyer <[email-masked]
> <mailto:[email-masked]>> wrote:
> >
> >     This RFC talks about how actual deployments can be surprising, making
> >     difficult to assess if a new protocol is good or bad.
> >
> >
> >
> >
> >     ---------- Forwarded message ----------
> >     From: [email-masked] <mailto:[email-masked]>
> >     To: [email-masked] <mailto:[email-masked]>,
> [email-masked] <mailto:[email-masked]>
> >     Cc: [email-masked] <mailto:[email-masked]>,
> [email-masked] <mailto:[email-masked]>
> >     Bcc:
> >     Date: Fri, 19 Feb 2021 17:28:17 -0800 (PST)
> >     Subject: RFC 8980 on Report from the IAB Workshop on Design
> Expectations vs. Deployment Reality in Protocol Development
> >     A new Request for Comments is now available in online RFC libraries.
> >
> >
> >             RFC 8980
> >
> >             Title:      Report from the IAB Workshop on
> >                         Design Expectations vs. Deployment Reality
> >                         in Protocol Development
> >             Authors:    J. Arkko,
> >                         T. Hardie
> >             Status:     Informational
> >             Stream:     IAB
> >             Date:       February 2021
> >             Mailbox:    [email-masked] <mailto:
> [email-masked]>,
> >                         [email-masked] <mailto:[email-masked]>
> >             Pages:      16
> >             Updates/Obsoletes/SeeAlso:   None
> >
> >             I-D Tag:    draft-iab-dedr-report-01.txt
> >
> >             URL:
> https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc8980__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CSUKYZ5Ik$
> <
> https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc8980__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CSUKYZ5Ik$
> >
> >
> >             DOI:        10.17487/RFC8980
> >
> >     The Design Expectations vs. Deployment Reality in Protocol
> >     Development Workshop was convened by the Internet Architecture Board
> >     (IAB) in June 2019. This report summarizes the workshop's significant
> >     points of discussion and identifies topics that may warrant further
> >     consideration.
> >
> >     Note that this document is a report on the proceedings of the
> >     workshop.  The views and positions documented in this report are
> >     those of the workshop participants and do not necessarily reflect IAB
> >     views and positions.
> >
> >     This document is a product of the Internet Architecture Board.
> >
> >
> >     INFORMATIONAL: This memo provides information for the Internet
> community.
> >     It does not specify an Internet standard of any kind. Distribution of
> >     this memo is unlimited.
> >
> >     This announcement is sent to the IETF-Announce and rfc-dist lists.
> >     To subscribe or unsubscribe, see
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf-announce__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CSB8Qw1b0$
> <
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf-announce__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CSB8Qw1b0$
> >
> >
> https://urldefense.com/v3/__https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CS5_sxVBU$
> <
> https://urldefense.com/v3/__https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CS5_sxVBU$
> >
> >
> >     For searching the RFC series, see
> https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CSmGRXXPo$
> <
> https://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CSmGRXXPo$
> >
> >     For downloading RFCs, see
> https://urldefense.com/v3/__https://www.rfc-editor.org/retrieve/bulk__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CSOG3yMq8$
> <
> https://urldefense.com/v3/__https://www.rfc-editor.org/retrieve/bulk__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CSOG3yMq8$
> >
> >
> >     Requests for special distribution should be addressed to either the
> >     author of the RFC in question, or to [email-masked]
> <mailto:[email-masked]>.  Unless
> >     specifically noted otherwise on the RFC itself, all RFCs are for
> >     unlimited distribution.
> >
> >
> >     The RFC Editor Team
> >     Association Management Solutions, LLC
> >
> >     _______________________________________________
> >     IETF-Announce mailing list
> >     [email-masked] <mailto:[email-masked]>
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf-announce__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CSB8Qw1b0$
> <
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf-announce__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CSB8Qw1b0$
> >
> >     _______________________________________________
> >     hrpc mailing list
> >     [email-masked] <mailto:[email-masked]>
> >
> https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/hrpc__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CSbLfQ0VU$
> <
> https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/hrpc__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CSbLfQ0VU$
> >
> >
> >
> >
> > --
> > Corinne Cath - Speth
> > Ph.D. Candidate, Oxford Internet Institute & Alan Turing Institute
> >
> > Web:
> https://urldefense.com/v3/__http://www.oii.ox.ac.uk/people/corinne-cath__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CS0V56tWI$
> <
> https://urldefense.com/v3/__http://www.oii.ox.ac.uk/people/corinne-cath__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CS0V56tWI$
> >
> > Email: [email-masked] <mailto:[email-masked]> &
> [email-masked] <mailto:[email-masked]>
> > Twitter: @C_CS
> >
> > _______________________________________________
> > hrpc mailing list
> > [email-masked]
> >
> https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/hrpc__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CSbLfQ0VU$
> >
>
> --
> Niels ten Oever, PhD
> Postdoctoral Researcher - Media Studies Department - University of
> Amsterdam
> Research Fellow - Centre for Internet and Human Rights - European
> University Viadrina
> Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio
> Vargas
>
>
> https://urldefense.com/v3/__https://nielstenoever.net__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CStXQ5Prw$
> - [email-masked] - @nielstenoever - +31629051853
> PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3
>
> Read my latest article on Internet infrastructure governance in New Media
> & Society here:
> https://urldefense.com/v3/__https://journals.sagepub.com/doi/full/10.1177/1461444820929320__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CSvn0_lIQ$
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Vittorio Bertola <[email-masked]>
> To: Niels ten Oever <[email-masked]>, [email-masked]
> Cc:
> Bcc:
> Date: Mon, 5 Apr 2021 10:31:15 +0200 (CEST)
> Subject: Re: [hrpc] [[email-masked]: RFC 8980 on Report from
> the IAB Workshop on Design Expectations vs. Deployment Reality in Protocol
> Development]
> > Il 05/04/2021 09:39 Niels ten Oever <[email-masked]> ha scritto:
> >
> > On 04-04-2021 14:21, Corinne Cath wrote:
> > << snip >>
> > > The report indicated both that "the protocol designers cannot affect
> market forces"
> >
> > This is quite interesting, especially taking into account that the IETF
> is mostly made up of people working for transnational corporations that
> concretely _are_ these market forces.
>
> After all this time, I do not remember exactly what was in my contribution
> to this workshop. However, part of my frustration at the IETF in the DoH
> discussion came exactly from the feeling above. Some people would
> participate in the creation of the standard with the hat of "individual
> participant", and would claim that the effects of the new standard on the
> market and on public policies were not the IETF's problem and not a direct
> consequence of the standardization work, but rather of how the new standard
> was used by implementers. Then, in their day job, they would switch their
> hat to "employee of company X" and they, or their colleagues, would
> implement the new standard in ways that purposedly created those effects. I
> found this a bit hypocritical.
>
> > Market forces are also somehow described as forces of nature that no one
> can predict or act against, which is also somewhat curious.
> >
> > Or perhaps it is a statement of believe, that the IETF is there to serve
> and facilitate the market? Which I think is not the case either because
> standards per definition exist to intervene in markets (by lowering costs
> and barrier of entry etc).
>
> Standards can be used to constrain the market through regulation, but they
> are more often meant to create a new market (especially in other SDOs,
> where standards precede implementation) or to foster a free, competitive
> market by removing technical barriers to competition after a market is
> started. I do not know if the IETF ever took any official stance on this,
> but if you also consider the known antipathy of the IETF for governments, I
> would expect the IETF to aim to "serve and facilitate the market" at least
> implicitly.
>
> --
> Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
> [email-masked]
> Office @ Via Treviso 12, 10144 Torino, Italy
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Stephane Bortzmeyer <[email-masked]>
> To: Corinne Cath <[email-masked]>
> Cc: Stephane Bortzmeyer <[email-masked]>, Hrpc <[email-masked]>
> Bcc:
> Date: Mon, 5 Apr 2021 14:17:25 +0200
> Subject: Re: [hrpc] [[email-masked]: RFC 8980 on Report from
> the IAB Workshop on Design Expectations vs. Deployment Reality in Protocol
> Development]
> On Sun, Apr 04, 2021 at 03:21:30PM +0300,
>  Corinne Cath <[email-masked]> wrote
>  a message of 312 lines which said:
>
> > This struck me as confusing, perhaps Stephane or someone else
> > present could clarify what the IETF considers to be the pieces it is
> > responsible for
>
> Easy, since this was my contribution to the workshop :-)
> <
> https://urldefense.com/v3/__https://www.iab.org/wp-content/IAB-uploads/2019/05/p4-bortzmeyer-dedr-workshop-encouraging.pdf__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CSX_uU0Z4$
> >.
>
> In summary: IETF's main responsability is in writing good
> standards. "Good" has many different definitions (it is not limited to
> "technical efficiency" since a protocol can be technically OK but
> still harmful) but my point is that IETF can act mostly through the
> standards it produces so it should focus on this task. Claiming that
> we must solve bigger problems is a recipe for trouble since we do not
> have direct leverage on them.
>
> BTW, let's be picky: this RFC was done by IAB, not IETF.
>
> > how those can as some people at the workshop suggested be used to
> > counter consolidation forces?).
>
> Indeed, the debate on that tend to be quite confused, for instance
> when people (and the RFC) mention DoH in the context of
> centralisation, while never being able to say *which part* of the DoH
> standard was wrong or what should have been done.
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Stephane Bortzmeyer <[email-masked]>
> To: Niels ten Oever <[email-masked]>
> Cc: [email-masked]
> Bcc:
> Date: Mon, 5 Apr 2021 14:23:21 +0200
> Subject: Re: [hrpc] [[email-masked]: RFC 8980 on Report from
> the IAB Workshop on Design Expectations vs. Deployment Reality in Protocol
> Development]
> On Mon, Apr 05, 2021 at 09:39:02AM +0200,
>  Niels ten Oever <[email-masked]> wrote
>  a message of 106 lines which said:
>
> > Market forces are also somehow described as forces of nature that no
> > one can predict or act against, which is also somewhat curious.
>
> The IETF is an US organisation and tend to stricly follow the US
> politics, the US view of the world, US current issues, for instance on
> terminology, etc.
>
> The RFC could have used a more "neutral" term such as "decisions by
> other actors", a term that would not have been tied to a specific
> political and economic system (capitalism, in its US variant). With
> such a term, I believe that we may agree with the point badly
> expressed in the RFC: IETF publishes standards, their actual
> implementation and deployment depends on many non-IETF things. May be a
> comparison with biology? DNA determines a lot of things in a living
> being but not everything since its expression goes through many
> complicated processes. Are RFC the DNA of the Internet, no less, no
> more?
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Stephane Bortzmeyer <[email-masked]>
> To: Vittorio Bertola <vittorio.bertola=[email-masked]>
> Cc: Niels ten Oever <[email-masked]>, [email-masked]
> Bcc:
> Date: Mon, 5 Apr 2021 14:29:38 +0200
> Subject: Re: [hrpc] [[email-masked]: RFC 8980 on Report from
> the IAB Workshop on Design Expectations vs. Deployment Reality in Protocol
> Development]
> On Mon, Apr 05, 2021 at 10:31:15AM +0200,
>  Vittorio Bertola <vittorio.bertola=[email-masked]>
> wrote
>  a message of 25 lines which said:
>
> > After all this time, I do not remember exactly what was in my
> > contribution to this workshop.
>
>
> https://urldefense.com/v3/__https://www.iab.org/wp-content/IAB-uploads/2019/05/p10-bertola-HowTheInternetWasWon-IABWorkshop2019onDeploymentReality.pdf__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CSbKoRHpM$
>
> > However, part of my frustration at the IETF in the DoH discussion
> > came exactly from the feeling above. Some people would participate
> > in the creation of the standard with the hat of "individual
> > participant", and would claim that the effects of the new standard
> > on the market and on public policies were not the IETF's problem and
> > not a direct consequence of the standardization work
>
> Please tell me what in RFC 8484 defines such or such characteristic of
> the current DoH deployment and usage. Then, same exercice with RFC
> 5321. Where do you find in RFC 5321 that Gmail and a few others have
> the majority of email?
>
> Also, the IETF is split on these issues: RFC 8404 is clearly
> anti-encryption (or "we want encryption but" and everyone knows that
> in this sort of sentences, it is what's after the but that matters)
> and reflects the viewpoint of network operators. RFC 8980 and 8890
> contain very unfair attacks against DoH.
>
>
> _______________________________________________
> hrpc mailing list
> [email-masked]
>
> https://urldefense.com/v3/__https://www.irtf.org/mailman/listinfo/hrpc__;!!KwNVnqRv!R6mD6HycEjYLhC4OnNyS0oTAYffLs5u30wTv9QUucKDrMyiz6A2xmfVrw6CSbLfQ0VU$
>