Re: [Gendispatch] Diversity and Inclusiveness in the IETF

Martin Thomson <> Sat, 27 February 2021 11:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 344423A1694 for <>; Sat, 27 Feb 2021 03:01:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=AmS+WuLJ; dkim=pass (2048-bit key) header.b=WiQTLPcK
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nfZlq8EZq3Gh for <>; Sat, 27 Feb 2021 03:01:03 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC13B3A1692 for <>; Sat, 27 Feb 2021 03:01:03 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id D0D4A6A5 for <>; Sat, 27 Feb 2021 06:01:02 -0500 (EST)
Received: from imap10 ([]) by compute1.internal (MEProxy); Sat, 27 Feb 2021 06:01:02 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=O1kHhY5BAHtmVpMw80EWDPw5PYXDnHe gxQz/qegdXuI=; b=AmS+WuLJMEhUjWzist1M7Ow6vuzla0aMuIbH37xajd5irYL h4IlDLGGAGMM1LwIcvxzKsh1BkzEKHkAWwOVki/U4RPYmD2rlL8KXsvgsTG8AuSL 5Gn8QHWQ+eSKIm+pH7ixnrlVXT91dF6gIRDurOuC3ADw2rWsreMc4eS+g8m3KFXW ry2jM5PW2LaREGiPlpRIhuTanalwmjTD04DL/wxWL+ZIBuIY96V2MMYEBCAeq0MQ /z0MOLAWxamVRdWAquQtMqpVdsyRUi2Vtui7f5dLpBP3ZTkdAnUE+a8owiCw8mog 47B6FFM19ZCnHQJYgIjmCVLwyyytT5G//e7m9fw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=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=O1kHhY 5BAHtmVpMw80EWDPw5PYXDnHegxQz/qegdXuI=; b=WiQTLPcKXAYdRRvDW7D1rq 4fH1oQ8ywHKnio0/vDLR24jpCJ5pNGMUbgoxHmd93vLNoYPevDUb7/EWr0BNiJKo mdDU2yVDqMklWnS0Gsfw00X5WGTZeSRz1WgvDpgueCDmRz6wFGJoivxox1zz6JBB K+zoP6iLHgXNK382qAjGkv/n8OqlDEHuvTuF5bBCKquDOwbbwa93DJmHEGOymdOp +WpIpdeZr/CSwP0n1Xkj5FjdrkVhagy8bjfluomLP+S9E1BKXYgppiRTnOQLR7nQ E3Uqrn06/9BrRny1hyQNga9J+UNhjjlkHlNyxTei6JbyX0n7NHvXee78eA6D6DUQ ==
X-ME-Sender: <xms:biY6YFugDcThdRbWUrdv5kHIWL39BIen6oxSVM9lEnmY8usxSTyjgQ> <xme:biY6YOckub2xVpA7MLJ3LJjJsyQPJ5gYA4Tp_MTdPaNqCRoDdpoWmQF6cOCNvixLS QjGLAAy-1e1jpIIiMc>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrleefgddvfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:biY6YIyYUG2OAoEbXfVoiN8NnZ4bIYjbdN1skBX76NKmPMH3rUo8gA> <xmx:biY6YMMnUkL4AnTqrfY_qsGFBaXq5B17Qno0QhNgZuQinYjqhO__RA> <xmx:biY6YF_kuwrEue1p9jXalVko0xWpfPPAyhAFiwbvSKwEjobS8o0Waw> <xmx:biY6YIKb0fpbeY3v7FlgNraYCD57hC3BHIw5kK9ckXnhSRmxSG_XqQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1922F4E02F2; Sat, 27 Feb 2021 06:01:02 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-141-gf094924a34-fm-20210210.001-gf094924a
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <> <LO2P265MB057322BA95B1B44D4175356BC29E9@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <> <> <> <> <> <> <> <> <> <>
Date: Sat, 27 Feb 2021 22:00:00 +1100
From: "Martin Thomson" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [Gendispatch] Diversity and Inclusiveness in the IETF
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Area Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 27 Feb 2021 11:01:05 -0000

On Fri, Feb 26, 2021, at 22:56, Vittorio Bertola wrote:
> My experience is the exact opposite - there were a number of times in 
> which I wanted to propose text for a document, but then I was pointed 
> at Github, and I am not at ease with it and did not have a lot of time 
> for it. So I gave up or, 

So anyone who asked you to submit an issue or write a pull request should be aware that sometimes they too need to make some effort.

As a request, asking someone to contribute on GitHub is fine. It isn't mandatory though. If you are able to, or you plan to contribute often, taking the effort makes it a lot harder for editors to take your input, track it, and integrate changes. However, if you don't, then it is best for all involved if the editors do the work of opening issues and writing pull requests (if that is how they manage the document). We did that for the IESG with QUIC, and for those who were unfamiliar with the process.

The goal should be always to take good input when it is offered. However, it always pays to make your input easier to act on. Clear, actionable input is more likely to result in actions, human nature being what it is. It is meeting in the middle. Editors are volunteering their effort too.

What we have found is that the discussion is sometimes more work to manage, for both editors and those involved, particularly when it comes to negotiating specific text. But generally the results are far superior.

To take an example, there was a discussion about the operational implications of path MTU discovery in QUIC. The initial issue was not especially clear to everyone involved, and the proposed text was not perfect either, but the resulting discussion clarified everything and the final text is crisp, precise, broadly acceptable, and - from my perspective - excellent. I have seen that work on a mailing list before and frankly, it is not so different in the end. Both methods can produce these good outcomes. I find the mailing list version quite a bit less efficient, that is all.

What really differs is that on the mailing list, you won't get that sort of engagement on every change. With QUIC, we had that level of engagement on every sentence that was added. So yeah, it cost more, in several ways. One way being that it was not suitable for casual engagement, something that I think needs work, as not every document needs that same level of intensity.

I am happy with the results and would recommend the process.

Understanding its limitations is important though.  We are still learning as a community, even if some of us are very familiar with it.  Collectively knowing what is possible, what works, what to avoid, and when, will take some time. I can't, however, accept any of the arguments presented so far that imply that this is bad enough to stop. And the suggestion that this is, or even might be, inherently exclusionary is one I just don't see. Our goal has always been to offer more ways to engage. At worst, I would suggest that your experiences are part of us all learning together.