Re: [Gendispatch] IETF transparency and diversity

Mark Nottingham <mnot@mnot.net> Thu, 08 April 2021 05:02 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: gendispatch@ietfa.amsl.com
Delivered-To: gendispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476523A3962 for <gendispatch@ietfa.amsl.com>; Wed, 7 Apr 2021 22:02:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.82
X-Spam-Level:
X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=UQzJ5sH0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SNFwQYKy
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVXkh0XPYMhr for <gendispatch@ietfa.amsl.com>; Wed, 7 Apr 2021 22:02:30 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D3C3A3961 for <gendispatch@ietf.org>; Wed, 7 Apr 2021 22:02:30 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 841BC5C010E; Thu, 8 Apr 2021 01:02:26 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 08 Apr 2021 01:02:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=Q 0tO9/Lry3a+gRYRVv0eQgt088cxCDXmx9SE63a2YdY=; b=UQzJ5sH0fUD67AfM4 aqHY0qLVC0aj9i8NcXEhKZO2Gm0V0ENg3XtyNCPdrvraSPU5qV9BeM994lglsuMM HnJGbLeSo56Gem3KsaZuW9bJ9HXOGpi5Wqtv8GubWGwAF0ilGgb/dBGUYW03HKg3 CKesYVJg5EtExt5JAnZhK3gr5zpw241uEioOCEkg+VLJvwR8j77rdO9uV2Sh1aPP keP8Szesez6utrPSyhyhXmzEzF5roUjVwglNLfFVg+8RZrm2t7PUj2Rauf+gUTs2 xxjWVy1F7Bky9vRVBRffgltFlJxZNjx4DELwXpEJnRYCXrHl7we15IlfTAcu9qVN 1g9ow==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=Q0tO9/Lry3a+gRYRVv0eQgt088cxCDXmx9SE63a2Y dY=; b=SNFwQYKy9q2pmaJ7wH6BlDTF49iRMYUUadkgMZ2wG+zif5geu2ypzYaPY x2Jn25NTJ+VTgxwDQEs3KNG+Yiw1Dv2pUPlXjZnzPauHIXSZxfYAqbo/5v/VC7UP F33QGtK/sET0RmrSY9WoLtCEbz1K1rk14C08HQHfvL5/XUzNTbtfUVK+t00VT0zd p6vIGyAIMH6OleBlbwEKp5SbvCG5Aku/29MFJ99GLDi8YUg9Kqd6NloXjVcjCMJa 0f9VISd3nmN+cVi1iPojbWDK0BKGyKBdjUt4zWemj5lM/UuHFqmlohCxrw4SEeW1 725VsRQNGkyi61RV3yo0dRBiMhC+A==
X-ME-Sender: <xms:YI5uYPoBKzwNJQsW4rt3Tb_tuGwDFSWIa_E6AlR5HDHbTHN1wWBoNw> <xme:YI5uYJqPhCjIiBKcl602jk1pL9Fx8SdePV-SFvp4tpjoPZcWLIygkR5UqJyppTC-l ah1FootcQ37i7wrQQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudejkedgleduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeevffffhfduteevvefhueffieegtdeutdehffeltefffedttdeggeejheeiueet teenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvd ehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:YI5uYMPYzT6hgekBdPmlLQY63XRgbUiknYoIGjDhO2FBfhRMY_1Gkw> <xmx:YI5uYC7pC-Fhhby1Hq5EqDmiqeBSku6nGqGq-OqKvCq6SEbXGR5SSQ> <xmx:YI5uYO5gPZxprqJtMcS2RJ38MV8TlvgoFjoEXJWAL2HNG5wt6bKvzQ> <xmx:Yo5uYOFdTtS4TQ3aq2GKfIzA6Y9M5P-RQKN-b6_LyNoxE8mDDti2qA>
Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 7537424005A; Thu, 8 Apr 2021 01:02:23 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <eedbc43b-82ea-2f95-d3db-69f601093a8d@gmail.com>
Date: Thu, 08 Apr 2021 15:02:20 +1000
Cc: "gendispatch@ietf.org" <gendispatch@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E0D59DE7-0858-4A9D-A17C-C6D4050BFF92@mnot.net>
References: <CAChr6Sxa6uY+nOzWW=MSXP_ekLaBSCTfjC2YcURi+kX0h2X+Rg@mail.gmail.com> <MN2PR11MB43668B598495DFDD060D33E2B5769@MN2PR11MB4366.namprd11.prod.outlook.com> <CAChr6SxZY6j+n1ps5C7R3ySePNpRt_9rdE5sB37FRmp6DBBVJA@mail.gmail.com> <3D340A9D-1A39-4ADA-BA27-E4E912CA6D03@akamai.com> <8d9a6f04-4d6d-288a-e901-aa17c42a5886@gmail.com> <CABcZeBM4e3vrNHA1+==n=KamRLwPUSWMgvQsTtVhA_uBaHaBug@mail.gmail.com> <65aec12d-715d-9447-65ae-70b14bbab717@cs.tcd.ie> <CAChr6SxYWW5CpY5t=ZD+xg+wH=YH5_nu+L_8dpP7_p+dED-ggA@mail.gmail.com> <2dfc430a-be5c-507d-1f63-9df7f71c9588@cs.tcd.ie> <eedbc43b-82ea-2f95-d3db-69f601093a8d@gmail.com>
To: Tony Rutkowski <rutkowski.tony@gmail.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gendispatch/DP6kChiYGFyVwP4wkQkLME5RXdY>
Subject: Re: [Gendispatch] IETF transparency and diversity
X-BeenThere: gendispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Area Dispatch <gendispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gendispatch/>
List-Post: <mailto:gendispatch@ietf.org>
List-Help: <mailto:gendispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gendispatch>, <mailto:gendispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2021 05:02:36 -0000

Tony,

At the risk of going wildly off-topic, I feel compelled to respond with my perspective.


> On 8 Apr 2021, at 2:35 am, Tony Rutkowski <rutkowski.tony@gmail.com> wrote:
> 
> Having watched dozens of standards bodies like the IETF try to assess themselves for the past forty plus years - generally not well - this list seems to follow the norm.  There are a relative handful of people on this list, and the participation is highly skewed.  3/4 of the posts are from just 21 people who are almost all insiders perpetuating status.  

If you want to make a claim like 'insiders perpetuating status', please support it; on the face, it seems more rhetorical than factual.


> Perhaps the most significant issue facing the IETF was raised by Phil on 31 March - namely that the lack of transparency of interest is an increasing challenge to the organisation

I don't agree that it's the most significant issue, by a long shot. As Kieth says, the ability for people to act as individuals here is a feature, not a bug. Furthermore, the cultural issues we're experiencing eclipse that issue easily.


> - especially with anticompetitive behavior becoming the subject of regulatory scrutiny and litigation.  

You seem to be claiming that the IETF's policy of individual participation, rather than company representation, is inadequate to prevent anti-competitive behaviour -- specifically the kinds that are currently under investigation, as widely reported in the news -- and therefore the IETF is somehow potentially liable. This connection is worth digging into, because this is not the first attempt to leverage the current headlines about competition law activity to argue for change in SDOs (see recent discussions in the W3C, for example).

EU and US competition law (statutory and case) as well as regulatory guidance documents have a lot to say about standards bodies regarding cartel behaviour (e.g., exclusion, price fixing). They also extensively cover abuse of dominance regarding IPR (patent ambush / standard-essential patents). However, they have very little to say (to date) regarding other forms of abuse of dominance in connection with SDOs -- and that's the focus of the activity that you reference.

So it's not yet clear what the relationship of standards bodies to these abuses should be. In particular, while personally I'd argue that standards are a factor that a competition regulator should take into account when considering this type of enforcement action, it isn't yet established that something becoming a standard offers any defence for abuse of dominance. Furthermore, a _responsibility_ for SDOs (and other horizontal agreements) to prevent these other theories of abuse has not been established. 

Given that, it's hard to avoid the conclusion that it would be premature for the IETF (or any other SDO) to reconfigure itself or change participation rules in reaction to these mere complaints (which may be resolved by courts in a variety of ways) and in absence of specific guidance from competition regulators. Instead, I'd very much like to see the IETF (and the W3C) enter into a dialogue with competition regulators to see if we can identify the attributes that they might find useful in standards and standards processes in making such determinations.

But ignoring all of that, let's say that Google (using them only as an example, since they're one of the focal points in these discussions) employees make some proposals without identifying themselves as such, and somehow no one notices that a) they come from Google, and b) they advantage Google over its competitors in a relevant market (noting that there's some latitude in how the effected market is connected to their power) without resorting to IPR abuse.

I'd argue that the IETF's lack of recognition for affiliation at worst has no effect on the outcome, and may even balance _against_ abuse of dominance in this circumstance. This is because proposals need to gain a rough consensus of all participants based upon technical merit (_not_ straight up/down voting), without regard to affiliation. Adding affiliation would only marginally increase visibility for any ex post enforcement action; if the process is properly run, it should not have great effect on the standards outcome itself.

Of much greater concern would be a potential abuse of dominance with effect upon a market that isn't well-represented in the IETF -- an issue which we tried to raise in RFC8890. Even then, linking the abusive effect to the market where the standard is operative could be quite problematic.


> The metrics of this list underscores the challenge - the principal proponents and decision shapers/makers lack attribution.

While your metric of attribution on this list is interesting, your claim about the leadership is simply not true; the IAB and IESG identify their members' affiliations on their respective home pages, and the NOMCOM is known to affiliation into account when selecting nominees. WG Chairs are selected with affiliation in mind and widely known, in my experience. Furthermore, proposals in the form of Internet-Drafts carry affiliation information; for example, it was very obvious and widely known that QUIC was a proposal from Google.


> During Steve Lukasik's last years, he viewed the IETF as one of his principal failures.  It was a great idea when he signed off on its initial precursor formation to get out-of-the-box collaboration among the researchers that DARPA was funding.  Attribution as well as collaboration incentives existed through the funding mechanisms.  However, when it was cut loose in the 1990s, any sense of attribution of individual contributors and decision shapers was lost.  As Phil notes, it opened the door was opened for all kinds of mischief; and in contrast to almost all other standards bodies, the IETF is alone in avoiding attribution. Getting the LLC to buy more liability insurance has its limits.
> 
> The IETF's diversity challenge is also tied into the lack of transparency.  If you crunch the numbers and examine how relatively few registrants for IETF meetings continue their participation, the organization is effectively self-distilling around a set of hardy perennials who are motivated by un-attributed factors to stick with the organization to pursue some obscure objectives.  Indeed, the IETF's substantial insularity and institutional self-aggrandisement coupled with a set of rapidly evolving technologies progressed in other far more active and effective bodies, does not bode well.

Again, 'substantial insularity and institutional self-aggrandisement' seems more rhetorical than a basis for useful discussion.


> So all of the above suggest that maintaining a generic IETF discourse list is probably a good thing.  --tony r 

That is a *huge* leap  -- can you show us your workings?

Cheers,


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