Re: Diversity and Inclusiveness in the IETF

Bron Gondwana <brong@fastmailteam.com> Tue, 23 February 2021 11:51 UTC

Return-Path: <brong@fastmailteam.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA793A2A2E; Tue, 23 Feb 2021 03:51:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=fastmailteam.com header.b=hXKizicP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KqfO2pUr
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 gQ1-PJQqKlRK; Tue, 23 Feb 2021 03:51:11 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85C5A3A2A2C; Tue, 23 Feb 2021 03:51:11 -0800 (PST)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9C6E25C0113; Tue, 23 Feb 2021 06:51:10 -0500 (EST)
Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Tue, 23 Feb 2021 06:51:10 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:cc:subject:content-type; s=fm2; bh=kK+2 huJHr1IKGuPHlq4X9gVF0YMy8F2XSEdgMcDpK64=; b=hXKizicP12fFf6luxgPh lgSPr+abgcenQASkTRzBxRdqCV/svK3gRd5MRXwWQCRLl0hodEMhqMiyEYKm7063 MXBmJB6NbqtHF9hLscS0YejGm+Gx63q6d7SwV1Sy84TezPf6Xa40WZM08kbNwRVJ ClJ8mELRK9V9LK+0MiEwqJilFpi0GGNEOhTZdp7yNhT8MXXJLh2CcAod6kRXv5Sk USIUv67KK3ulnU9MCnafiUSjwLgVV/9+LgeaOIoxNJAy805n+/+ms1iCDjwdHu/L uQ6Zmx0I5ri7coqYh2AOnFupZLwPZhlHtF520s2nP2kWmNL6rVt6j+ok6UPH7kZV yg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=kK+2hu JHr1IKGuPHlq4X9gVF0YMy8F2XSEdgMcDpK64=; b=KqfO2pUr8VR8Vo4unq1hrL GixADUsQ18QTqLegVFDOgSn1kv832qs5WHVPENCi6/gIIMrjDz6U4Sgq7nwcLRHh K8fYXeIyNwT0LSzfXTcl41Z0WUq7JUdGcHhywZ9+mtmqRCewDau1GpI3jwuaHe/I Kp7bc4NSL7nFl15/4JNvhQLQIGrI7ig7tUXtKb3nlp6qa4eOo5fIClcLiHUo8DRe b/Z7FkQG7JqtqI9ElnijQuvI8fE7N0seXdK6yPN4UsOLhkapX7b2AGko3kab/X6m gEEZkArqaDGAd8KnutxeRxT1BXTb4cCOKPnEc87JYv6t59IdJ9d07yU+xjEGhVxA ==
X-ME-Sender: <xms:Luw0YDznO_CoAeDw2eOXex-vd1-yZLsBmjxJB3nywfXgxnlq1KDecA> <xme:Luw0YLR4h5YlDb8Xs9bqzUjYGzmD0W77A3oru3__dUeQjPAOO_ZsN9uhIzDmfjQOZ _cYj5Yu__Y>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrkeehgdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsegrtderreerreejnecuhfhrohhmpedfuehrohhn ucfiohhnugifrghnrgdfuceosghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhmqe enucggtffrrghtthgvrhhnpeehtedtjedugfdtgeevffeludeljedvfffhtdfhhfffffdu veegkeejvdefveekfeenucffohhmrghinhepfihikhhiphgvughirgdrohhrghdpihgvth hfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm
X-ME-Proxy: <xmx:Luw0YNV0cCMFufKuijQZZ9UhTHiB5Vy98Ggp7GsFmRecRAM2KXPh2g> <xmx:Luw0YNiIGM9ySNp-ro52Mp1JtzGfsm49wZxCrnNTGcAlusYu1gu33g> <xmx:Luw0YFAYyOt2VUGy6hht4hNW_P4TTuK0SWbN7eExgtMBt99lThBhwQ> <xmx:Luw0YIp3JcBDfuk5wnuAiMtjxukgk9C_1xl8geQ2v173Pnbt1gL8uQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1B7C33604EE; Tue, 23 Feb 2021 06:51:10 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a
Mime-Version: 1.0
Message-Id: <d6648437-332b-4668-a1c7-591f2c287539@dogfood.fastmail.com>
In-Reply-To: <AM0PR08MB371669108E9CEA561BEC9EF6FA809@AM0PR08MB3716.eurprd08.prod.outlook.com>
References: <37eecb9b-f0eb-e21c-b162-b1f0339e4981@si6networks.com> <3c2d646d-f18d-4d88-b458-29dbd486432b@beta.fastmail.com> <AM0PR08MB371669108E9CEA561BEC9EF6FA809@AM0PR08MB3716.eurprd08.prod.outlook.com>
Date: Tue, 23 Feb 2021 22:50:49 +1100
From: "Bron Gondwana" <brong@fastmailteam.com>
To: "Hannes Tschofenig" <Hannes.Tschofenig@arm.com>, "ietf@ietf.org" <ietf@ietf.org>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: Diversity and Inclusiveness in the IETF
Content-Type: multipart/alternative; boundary=61e0360afb2240f5b3ad96af2a1856fa
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ptEnlH_EorVyZY0_KnE5N1DSUrw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Feb 2021 11:51:15 -0000

Without wishing to litigate the entire issue here (happy to remove the wider IETF list and just talk on the OAuth group), we never brought any work to the OAuth group because everybody who we spoke to warned us that nothing would get done.

There's a term "missing stair" https://en.wikipedia.org/wiki/Missing_stair which describes this phenomenon, where "everybody knows" something, but new participants are forced to discover it through either having someone tell them quietly, or just notice it for themselves.

...

Just as an anecdote, the last time I bothered to attend an OAuth meeting in person I had this to say about it on our internal slack channel when asked:"they can't agree about what they don't agree on".

The topic that had taken basically the entire meeting and had been totally unproductive - was a particular key in a JSON Web Token going to clash with a reserved word in either javascript itself or one of the other environments in which this token had to be evaluated.  There were people saying "this won't work, just rename the key" and others saying "I like this name and insist upon us keeping it".  No progress was made that day.

In fact, here's the extract of my report on the OAuth meeting at IETF102 (a detailed long email with pictures of poutine, icecream, and a report on every session I attended).  Names extracted to protect the others involved, but other text left exactly as it was, complete with typoes:

> *Thursday 19th: (Aug 2018)*
> 
> *9:30am* OAUTH <https://datatracker.ietf.org/meeting/102/materials/agenda-102-oauth-03>:  Fecking OAUTH as they say.  I came out of this saying "they can't even agree about what they don't agree on".  <Name redacted> says it was even worse in the past.  What a fustercluck.  Don't expect anything workwhile out of this group unfortunately.  <Other name redacted> and I were just looking at each other like WTF the entire time.

Maybe it's become heaps better since then.  But I wouldn't want to have been a new participant trying to get anything done in that session.

...

The authentication flow as originally put into JMAP (before it came to the IETF) can be seen in the initial draft here if you're interested:

https://www.ietf.org/archive/id/draft-jenkins-jmap-00.txt

But we decided in the interests of expediency to just drop it rather than trying to progress that work anywhere at the IETF.

Regards,

Bron.

On Tue, Feb 23, 2021, at 22:00, Hannes Tschofenig wrote:
> Hi Bron,

>  

> I have to respond to your statements about the OAuth working group below.

>  

> While we do not pay attention to keeping the charter page up-to-date, we have been able to advance our documents, produce many implementations, and got those deployed all over the Internet.

>  

> The bar for acceptance of new work varies among working group in the IETF. Some working groups develop technology that got widely deployed and hence randomly changing specs isn’t such a great idea because you have to consider the deployment situation as well. This is a situation many IETF working groups face. Reaching (widespread) deployment is great on one hand and a pain on the other.

>  

> There are other groups, which are early in their lifecycle. In those groups you do not need to worry about deployments, backwards compatibility or even any source code.

>  

> In general, Rifaat and I are always open for anyone in the IETF (and outside) to reach out to us, if they want to bring new work forward to the group. Sometimes proposed work fits into the group and sometimes it does not. The work on JOSE, for example, was put into a separate working group even though it was initially developed for use with JSON Web Tokens.

>  

> I don’t recall having chatted with you or with someone from the JMAP community on the use of OAuth. Sorry if my memory does not serve me well today.  Typically, applications just use OAuth and therefore there is no need to reach out to the OAuth working group.

>  

> Ciao

> Hannes

>  


> *From:* ietf <ietf-bounces@ietf.org> *On Behalf Of * Bron Gondwana
> *Sent:* Tuesday, February 23, 2021 5:20 AM
> *To:* ietf@ietf.org
> *Subject:* Re: Diversity and Inclusiveness in the IETF

>  

> Thanks Fernando,

>  

> I would add to this document something about inertia, backwards compatibility and existing dysfunction.

>  

> Many ideas are shut down because they aren't in the right place, or don't fit comfortably into the existing corpus of IETF documents.

>  

> When we brought JMAP to the IETF it was after a long process of socialisation, and still there was significant work in the first couple of meetings just to convince people that "this is worth doing, the existing work the IETF has done in this neighborhood is not sufficient".

>  

> JMAP also had an authentication scheme in it originally.  It was a good authentication scheme, but applications don't do authentication schemes, that's the bailiwick of OAUTH, where ideas go to die (in my experience, that working group has been dysfunctional for my entire time at IETF - exhibit 'A' being the "Milestones" section of the about page, which lists 6 items all due in 2017)

>  

> So we just removed all mention of authentication method and handwaved "the connection will be authenticated", because we wanted to publish something during the decade with years starting '201'.

>  

> ... all that to say.  One of the biggest barriers to entry in the IETF is stumbling across an area in which no work is able to progress due to entrenched issues within that area.

>  

> And I'm not arguing for "no barriers to entry", because there needs to be a sanity check that we're actually producing high quality specifications, and that our specifications are compatible with each other so the entirety of the IETF's work product is a coherent whole.  But it's hard to get started if you don't already have the connections to have your work sponsored by somebody who already knows their way around the IETF's idiosyncrasies.  I'm doing some of that sponsoring myself now for the people from tc39 who are trying to get the IETF to look at defining an extended datetime format.

>  

> Cheers,

>  

> Bron.

>  

> On Tue, Feb 23, 2021, at 11:07, Fernando Gont wrote:

>> Folks,

>>  

>> We have submitted a new I-D, entitled "Diversity and Inclusiveness in 

>> the IETF".

>>  

>> The I-D is available at: 

>> https://www.ietf.org/archive/id/draft-gont-diversity-analysis-00.txt

>>  

>> We expect that our document be discussed in the gendispatch wg 

>> (https://datatracker.ietf.org/wg/gendispatch/about/). But given the 

>> breadth of the topic and possible views, we'll be glad to discuss it

>> where necessary/applicable/desired.

>>  

>> As explicitly noted in our I-D, we're probably only scratching the 

>> surface here -- but we believe that our document is probably a good 

>> start to discuss many aspects of diversity that deserve discussion.

>>  

>> Thanks!

>>  

>> Regards,

>> -- 

>> Fernando Gont

>> SI6 Networks

>> e-mail: fgont@si6networks.com

>> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

>>  

>>  

>>  

>>  

>>  

>  

> --

>   Bron Gondwana, CEO, Fastmail Pty Ltd

>   brong@fastmailteam.com

>  

>  

> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  brong@fastmailteam.com