From nobody Sun Aug 9 10:50:08 2020 Return-Path: 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 DDBF53A0831 for ; Sun, 9 Aug 2020 10:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=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=ischool-berkeley-edu.20150623.gappssmtp.com 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 aiQ1TUwD7ABW for ; Sun, 9 Aug 2020 10:49:55 -0700 (PDT) Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33B63A0833 for ; Sun, 9 Aug 2020 10:49:54 -0700 (PDT) Received: by mail-qk1-x744.google.com with SMTP id 2so6392116qkf.10 for ; Sun, 09 Aug 2020 10:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ischool-berkeley-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Pc2pzQ+Ji+mBQuuxu1woSt0NJXwPXlUe3/ysyyvIYG4=; b=R8BRB4ZdzuoSBn2fY7FCIFo9s31hf5UIhUAMCJskZnyvWMjEVdQ8WViWNmckkbcxKe W8Xmx4Zcl0gbvF0nFdZEFL1ge/LAG0inzmigCic/HdyXJYN80haErLAW6WKIOly5RBJT IvD43ueFl96i7ri/K31+OwV+2wWre+LLQg+7QCRYns+D6MxWco46Fajy7tRCM040XBqz OPgLKz4vWmnLW5J/3eBM3AeVsxIgEnJNpFiumfQ+j8NWF7n1DP75qA0fBmmZJ5jKk/gh Y0ShDxC4zokPFO+OLtBVQm6YTIZzcfF9uA+EQc/h7ehOP7IxfhaBWUg32SegWvaGCM92 W4vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Pc2pzQ+Ji+mBQuuxu1woSt0NJXwPXlUe3/ysyyvIYG4=; b=an+iFmnBqrhcOuSQsHkR/ZgiETIX/a+FSB35tIeOGpSNB8yMMs+sEMP9snQKTgIXDc a26JLstQ4XEKjwLQM/SAvGLLP4mK5VY/BX+B9oSXiYgqD56JkuZSculGYgMu6aQajQCH taFddJkWeiaVsYK0Cj776Z7L0z5pykRgMFL1CJ/Rgz8W872tstQRCuPOvw1/vDbwfjmm A2gwtl9CUsZqbiJp/UbxjWkJOnfd3ReLwQgKzHUBu59ZTQXC1lsKZUqy+1c7X6feAEGe xQB4tqmOcJrAfABnlg8W2qmLj9r8tjS63dAboFHq8v1whMSocZ8U9tK7glDfZt6Tol1W 5Ngg== X-Gm-Message-State: AOAM531Ij77b6+lyvfObvVIwirK1R5sayNffhsMf2Ft/PLYUEAj1+KNk 0l9eTwAuSfMdPYv0FmSyzNCvidKiAj8= X-Google-Smtp-Source: ABdhPJzLTXwJFCMBskgaymy1oVnQGKmIf5LRuFNcU7kOYE7ZKWj7X/ILGqrO/2NNRx9YXJLYTMollg== X-Received: by 2002:a37:8047:: with SMTP id b68mr21288801qkd.299.1596995393663; Sun, 09 Aug 2020 10:49:53 -0700 (PDT) Received: from [192.168.1.2] (cpe-71-70-181-162.nc.res.rr.com. [71.70.181.162]) by smtp.gmail.com with ESMTPSA id o47sm13919201qtk.19.2020.08.09.10.49.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Aug 2020 10:49:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Nick Doty In-Reply-To: Date: Sun, 9 Aug 2020 13:49:51 -0400 Cc: Pete Resnick , gendispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> References: <20200722163704.8ADB21D61A46@ary.qy> To: Alissa Cooper X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Gendispatch] draft-knodel-terminology-02 X-BeenThere: gendispatch@ietf.org 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: Sun, 09 Aug 2020 17:50:08 -0000 On Jul 23, 2020, at 3:00 PM, Alissa Cooper wrote: >=20 >> On Jul 22, 2020, at 10:19 PM, Pete Resnick = wrote: >>=20 >> On 22 Jul 2020, at 16:31, Bob Hinden wrote: >>=20 >>> To Pete=E2=80=99s email, where should this work take place? >>=20 >> See my other response, but this is part of the question the WG is = meant to answer. Do we think we need a WG or BOF to work on this? Then = we're probably going to suggest discussing on a new mailing list. If we = think this belongs somewhere else, e.g., I could imagine that we decide = that it should be part of the RFC Editor's responsibility, then we could = ask the IETF Chair or LLC to take up the work. But we've got a whole = menu of options. >=20 > In addition to the ideas I=E2=80=99ve seen discussed on the list thus = far (in the draft, updates to the RFC Style Guide, changes to the idnits = tool), I=E2=80=99ve been wondering whether writing up some guidance for = Gen-ART reviewers could also be part of the mix here. This could have a = simple focus on checking for clear, descriptive metaphors, or it could = be more detailed. In any event since the directorate reviews every = document before publication that might be an additional tool to = consider. >=20 > I would also note that since our collective understanding of the = impact of language evolves over time, it might be useful to think about = the line between what might get memorialized in an RFC (say, a broader = statement of policy or principle that doesn=E2=80=99t change often) = versus what might get documented in a form that could be more detailed = and easier to update like the I-D checklist [1] (which is fairly out of = date but technically easier to update than an RFC) or an IESG statement. +1 to the use of tools including the Style Guide, but also to = documentation for reviewers. To give an example from another standard-setting organization, W3C has = recently updated their Manual of Style with a brief section on inclusive = terminology: https://w3c.github.io/manual-of-style/#inclusive That is informal guidance (and can be updated frequently), with a = citation to the W3C Code of Ethics and Professional Conduct, which can = speak more directly to the reasoning for inclusion and professionalism = in the standard-setting process. I=E2=80=99m grateful to the IESG for their statement noting the harm of = exclusionary language, which is important to hear from community = leaders. Most of the work of language changes will be made by = individuals in smaller ways. Earlier this year, a quick review from a = collaborator found usage of =E2=80=9Cwhitelist=E2=80=9D/=E2=80=9Cblacklist= =E2=80=9D in one of my older drafts, and a PR made it easy to correct = the document, which also improved the precision of the metaphor in use. = I think most authors will be similarly grateful for the feedback and = that getting those comments in reviews done earlier in the process will = make it easier for authors and readers. Thanks, Nick= From nobody Sun Aug 9 16:19:54 2020 Return-Path: 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 26DD03A0766 for ; Sun, 9 Aug 2020 16:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=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=gmail.com 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 wmOAnDdzb2Ea for ; Sun, 9 Aug 2020 16:19:51 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43A53A074B for ; Sun, 9 Aug 2020 16:19:51 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id y6so3903644plt.3 for ; Sun, 09 Aug 2020 16:19:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fyJm4uCL1NMhux0n+Rt1y2XckzIuv/sh2WZUUnSr6p0=; b=kwdmdAU2EJ8nP6foYzTNGTwQkn0tJQ19AJgJY2MoLPlTyaANHKBKEn2D82yAYDOIvA 4Za6vzlaeeLmDkBOS0NwDhRaX9sSnmC16P2nmbmrkp5qA4DKgRCt6nTmm+zsZF1P1jh2 D9kwCmPQWU14/wZpmccLZo0Gznw5bIRcC8A8XXVjRpuK3wHH13DyEY1vUtjx/HCRksgL Pe7APiEm9HZt8GCbdrsh0ZoU79Zn3eIh77C6qUrVpBlpqyZO7OXujm0QbBYsDDHgw7bt 3bMlEZomugCsdNiAjVtt1TPQspOGA0sLxnwuL6YUcMjmiYIpBrda/H561uzi5ROUYga9 qObQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fyJm4uCL1NMhux0n+Rt1y2XckzIuv/sh2WZUUnSr6p0=; b=ZpvWbgbnyqr0/4xNIpo1bTDClWSKFWUiC7NloHb9dx3Fe09UyARfAppJl6/6/bF+TN LqaROSAIJsVi6C1M8nwVLTAXyMi4be/hrcs+n/v6xC0wwk2IIg4ejthkeGJpasqYW16H 5MFCJWk12o9O/Kr9JI9khHUgGgkFfI7weDyqPVBDKCBCrag8Mmg2tK/DWf0hGoo31Pxo 8GnV4JBAJnh93NDdTWadt2L9cIU6cJOf0sfh5hJiO8kX7tMyGpHHRfDvzLKqXwtLlAx1 WZY+kWbRd6syMkRpvHUCO8dInF3BIpbU92RrvKZ5ri26tg6+gaFl0ut7BD/pLCBxP5fQ /UEw== X-Gm-Message-State: AOAM530US35g6eeXDAIemFQNTiA6f/BLDJ4I1FxEseSgrpZqOi9dZGtl zlcbo6gxAEzv8EPGU0AmDndnvIigWcw= X-Google-Smtp-Source: ABdhPJwUlHYoQAezRywE4UI2WeU+7J+MCvIdwSuA8eFFxxMTctTYRlZK9HXN8mg1kczs8PtimEt7aQ== X-Received: by 2002:a17:90b:684:: with SMTP id m4mr24376736pjz.4.1597015190703; Sun, 09 Aug 2020 16:19:50 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id g10sm16903532pjs.20.2020.08.09.16.19.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Aug 2020 16:19:50 -0700 (PDT) To: Nick Doty Cc: gendispatch@ietf.org References: <20200722163704.8ADB21D61A46@ary.qy> <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> From: Brian E Carpenter Message-ID: <14018709-49ab-0cb8-343c-e4edbcde28ca@gmail.com> Date: Mon, 10 Aug 2020 11:19:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Gendispatch] draft-knodel-terminology-02 X-BeenThere: gendispatch@ietf.org 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: Sun, 09 Aug 2020 23:19:53 -0000 On 10-Aug-20 05:49, Nick Doty wrote: =2E..> +1 to the use of tools including the Style Guide,=20 The RFC Editor style guide is not the IETF's to change. Unless we use some pretty advanced AI, I don't think tools that flag bad words are going to be welcomed. > but also to documentation for reviewers. If the documentation is "watch out for inappropriate language", I think that is what reviewers have been doing for many years. Setting aside well-entrenched terms of art, I have very rarely seen inappropriate=20 language in documents that came my way as a GenART reviewer. From a quick scan of the reviews I've written since 2007, I haven't in fact found *any* objectionable language at the IETF Last Call stage. > To give an example from another standard-setting organization, W3C has = recently updated their Manual of Style with a brief section on inclusive = terminology: > https://w3c.github.io/manual-of-style/#inclusive Rather than go into details, let me just assert that there is no consensus in the IETF on the W3C's specific list of terms to avoid. (Also, their table would make "to they" and "theirs ability" valid constructs; it wouldn't get past GenART review on my watch.) > That is informal guidance (and can be updated frequently), with a citat= ion to the W3C Code of Ethics and Professional Conduct, which can speak m= ore directly to the reasoning for inclusion and professionalism in the st= andard-setting process. >=20 > I=E2=80=99m grateful to the IESG for their statement noting the harm of= exclusionary language, which is important to hear from community leaders= =2E Most of the work of language changes will be made by individuals in s= maller ways. Earlier this year, a quick review from a collaborator found = usage of =E2=80=9Cwhitelist=E2=80=9D/=E2=80=9Cblacklist=E2=80=9D in one o= f my older drafts, and a PR made it easy to correct the document, which a= lso improved the precision of the metaphor in use. I think most authors w= ill be similarly grateful for the feedback and that getting those comment= s in reviews done earlier in the process will make it easier for authors = and readers. Yes, but a blocklist/allowlist like the W3C's will not get very far in the IETF's world of rough consensus. I think we have to be more subtle. For example, words like "oppressive" and "inclusive" or "exclusionary" are themselves value judgments and carry a certain amount of bias with them. You can clearly see that in the endless loop of discussion on the IETF main lits. I'd much rather we say "inappropriate" or "unprofessional" when defining our topic. Brian From nobody Wed Aug 12 08:54:30 2020 Return-Path: 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 B392B3A1378 for ; Wed, 12 Aug 2020 08:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 e5X4KkZyIxKE for ; Wed, 12 Aug 2020 08:54:27 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [IPv6:2001:67c:27e4::14]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1033A10E5 for ; Wed, 12 Aug 2020 08:54:26 -0700 (PDT) Received: from [IPv6:2800:810:464:1f7:2050:70d7:6aa2:63d2] (unknown [IPv6:2800:810:464:1f7:2050:70d7:6aa2:63d2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 0223A28397B; Wed, 12 Aug 2020 15:53:50 +0000 (UTC) To: Brian E Carpenter , Nick Doty Cc: gendispatch@ietf.org References: <20200722163704.8ADB21D61A46@ary.qy> <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> <14018709-49ab-0cb8-343c-e4edbcde28ca@gmail.com> From: Fernando Gont Message-ID: <6e2e232a-2565-c87a-9ead-f1ca23323224@si6networks.com> Date: Wed, 12 Aug 2020 12:28:02 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <14018709-49ab-0cb8-343c-e4edbcde28ca@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Gendispatch] draft-knodel-terminology-02 X-BeenThere: gendispatch@ietf.org 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: Wed, 12 Aug 2020 15:54:29 -0000 On 9/8/20 20:19, Brian E Carpenter wrote: [...] > > Yes, but a blocklist/allowlist like the W3C's will not get very far in > the IETF's world of rough consensus. I think we have to be more subtle. > For example, words like "oppressive" and "inclusive" or "exclusionary" > are themselves value judgments and carry a certain amount of bias > with them. You can clearly see that in the endless loop of discussion > on the IETF main lits. I'd much rather we say "inappropriate" or > "unprofessional" when defining our topic. Even more... they result in value-judgement discussions that somehow ironically seem to mostly exclude what would be the most affected/oppressed/excluded parties (so to speak). Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Wed Aug 12 10:57:52 2020 Return-Path: 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 A613B3A1405 for ; Wed, 12 Aug 2020 10:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Rex4QOWsx_MX for ; Wed, 12 Aug 2020 10:57:46 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568893A13FB for ; Wed, 12 Aug 2020 10:57:46 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QEY2GU7QPWA78@wwwlocal.goatley.com> for gendispatch@ietf.org; Wed, 12 Aug 2020 12:57:46 -0500 (CDT) Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QEY00B5VPW41D@trixy.bergandi.net> for gendispatch@ietf.org; Wed, 12 Aug 2020 10:57:40 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Wed, 12 Aug 2020 10:57:40 -0700 Date: Wed, 12 Aug 2020 10:57:44 -0700 From: Dan Harkins In-reply-to: <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> To: gendispatch@ietf.org Message-id: <957a094c-dba8-ed24-74da-8bd865470d71@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local) References: <20200722163704.8ADB21D61A46@ary.qy> <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> X-PMAS-Software: PreciseMail V3.3 [200810] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [Gendispatch] draft-knodel-terminology-02 X-BeenThere: gendispatch@ietf.org 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: Wed, 12 Aug 2020 17:57:51 -0000 On 8/9/20 10:49 AM, Nick Doty wrote: > I’m grateful to the IESG for their statement noting the harm of exclusionary language, which is important to hear from community leaders.   I certainly am not!   The IESG statement is merely an assertion. It does not say how language excludes or who is excluded by language. And it does this intentionally because the reasoning is likely fallacious or faulty and exposes the person making the assertion to uncomfortable further questions.   draft-knodel-terminology says the quiet parts out loud though, something the IESG statement avoided. And while the draft tries to be cute by saying those quiet parts out loud in a rhetorical question, it's still a rhetorical question and the answer is implied. Those quiet parts said out loud are that the exclusionary language is "master" and "slave" and those excluded are black people. We are asked to consider, "what impact [reading this word] might have on black students who are debating whether or not to enter science and technology careers at all?" The question is answered since the draft goes on to recommend action to get rid of these words.   The etymology of "slave" is "Slav" [1] and the Slavs are white people from Easter Europe who were subjected to slavery from the 9th century until the early 20th when the last of Europe's slave markets closed. So if historical experience with slavery is enough to cause someone to question whether to enter a STEM field after seeing the word "master" or "slave" it should be white people, specifically Slavs.   But it's absurd to suggest white people do not enter STEM degrees because of this word. So why would black people whose experience with slavery is almost entirely in North America and whose experience is dwarfed by that of the Slavs? And this is where the IESG statement and draft-knodel-terminology fail.   What they're saying is white people would never react that way but black people would. It's fundamentally a racist statement.It's the racism of diminished expectations of an "other" group. Take a look at the make-up of the authors of draft-knodel-terminology and the IESG: white, western-educated, affluent, the opposite of this "other" group they're white-knighting for.   draft-knodel-terminology is racist and unless the IESG can explain themselves, the implication is that they are also making a racist assertion.   This has no place in the IETF. This draft should be dispatched to the nearest round file and the IESG should retract their statement and apologize for it.   regards,   Dan. [1] https://ahdictionary.com/word/search.html?q=slave From nobody Wed Aug 12 12:25:27 2020 Return-Path: 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 43D5A3A080E for ; Wed, 12 Aug 2020 12:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 v0U5qT787eUq for ; Wed, 12 Aug 2020 12:25:25 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F022E3A0856 for ; Wed, 12 Aug 2020 12:25:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id B50A1B849787 for ; Wed, 12 Aug 2020 14:25:20 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaVCQRgK_EJm for ; Wed, 12 Aug 2020 14:25:16 -0500 (CDT) Received: from [172.16.1.6] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 7BD37B849775 for ; Wed, 12 Aug 2020 14:25:16 -0500 (CDT) From: "Pete Resnick" To: gendispatch@ietf.org Date: Wed, 12 Aug 2020 14:25:02 -0500 X-Mailer: MailMate (1.13.1r5699) Message-ID: <80EE288E-8BA1-4993-9FAE-834DD55153B9@episteme.net> In-Reply-To: <957a094c-dba8-ed24-74da-8bd865470d71@lounge.org> References: <20200722163704.8ADB21D61A46@ary.qy> <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> <957a094c-dba8-ed24-74da-8bd865470d71@lounge.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [Gendispatch] draft-knodel-terminology-02 X-BeenThere: gendispatch@ietf.org 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: Wed, 12 Aug 2020 19:25:26 -0000 All, We are not going to have a discussion of the merits of the IESG statement on this list. Nick's statement of gratitude on the list last week was not on topic, but was appropriately not taken up as a point of discussion. Dan's taking it up is not on topic either, and let's please drop that discussion now. As to draft-knodel-terminology: The initial discussion (which I ask you to please hold until the interim, which Francesca and I will schedule ASAP) is about how to dispatch the document. That will involve to some degree talking about the whether it's worth pursuing the overall endeavor, independent of the document itself, but please let's focus the discussion toward the dispatch question primarily. Also, describing documents as "tr[ying] to be cute" or talking about its "rhetorical" aims is commenting about tone and style, not the central points of the document. Not only is that irrelevant to the dispatch discussion, it's inappropriate. Finally, please take discussions of what is or is not "racist" or "racism" off of this list. There is lots of good literature out there to educate yourself on how those words are used (I can dig up some references if you need them), but we are not going to have a productive discussion if we spend our time wielding those words without a common definition. So, again, let's leave this topic alone until the interim. Thanks, pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Wed Aug 12 14:11:27 2020 Return-Path: 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 DF7E63A0B94 for ; Wed, 12 Aug 2020 14:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.85 X-Spam-Level: X-Spam-Status: No, score=-2.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 BLsw5vNZA8IM for ; Wed, 12 Aug 2020 14:11:24 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28163A0B92 for ; Wed, 12 Aug 2020 14:11:24 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QEY2HD9QYV02I@wwwlocal.goatley.com> for gendispatch@ietf.org; Wed, 12 Aug 2020 16:11:24 -0500 (CDT) Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QEY00K48YUTBZ@trixy.bergandi.net> for gendispatch@ietf.org; Wed, 12 Aug 2020 14:11:18 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Wed, 12 Aug 2020 14:11:18 -0700 Date: Wed, 12 Aug 2020 14:11:23 -0700 From: Dan Harkins In-reply-to: <80EE288E-8BA1-4993-9FAE-834DD55153B9@episteme.net> To: gendispatch@ietf.org Message-id: <38e622da-2a6e-865c-0d12-76b22ab03b55@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local) References: <20200722163704.8ADB21D61A46@ary.qy> <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> <957a094c-dba8-ed24-74da-8bd865470d71@lounge.org> <80EE288E-8BA1-4993-9FAE-834DD55153B9@episteme.net> X-PMAS-Software: PreciseMail V3.3 [200810] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [Gendispatch] draft-knodel-terminology-02 X-BeenThere: gendispatch@ietf.org 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: Wed, 12 Aug 2020 21:11:26 -0000   Hi Pete, On 8/12/20 12:25 PM, Pete Resnick wrote: > Finally, please take discussions of what is or is not "racist" or > "racism" off of this list. There is lots of good literature out there > to educate yourself on how those words are used (I can dig up some > references if you need them), but we are not going to have a > productive discussion if we spend our time wielding those words > without a common definition. > > So, again, let's leave this topic alone until the interim.   The thing is, draft-knodel-terminology broached this subject originally.   It describes master-slave as "a more egregious example of racism." The term. They're calling a technical term racism. Of course it's not the worst though as there's another example it gives that "is more pervasive and therefore more insidious." The draft warns of egregious and insidious racism in documents! And I am assured it is not satire.   draft-knodel-terminology goes further, though, to actually name and shame an individual for a statement (from 2008!!!) that it describes as "an indicator of actual racism in the community." Actual racism! This is highly unprofessional and has no place in the IETF community.   I'm educated enough about racism, thank you very much for your offer but I'm good, that's why I feel qualified to call the draft out for it. But I think it's kind of unfair for you to discourage use of a word that is used quite a bit in the draft we are talking about dispatching.   regards,   Dan. From nobody Wed Aug 12 15:06:35 2020 Return-Path: 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 5313C3A0C1E for ; Wed, 12 Aug 2020 15:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 DEgf8kwz_fYk for ; Wed, 12 Aug 2020 15:06:32 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4053A0C1F for ; Wed, 12 Aug 2020 15:06:18 -0700 (PDT) Received: from xse221.mail2web.com ([66.113.196.221] helo=xse.mail2web.com) by mx16.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1k5ysv-0002j3-Kr for gendispatch@ietf.org; Thu, 13 Aug 2020 00:06:15 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4BRkLB491qz9gv for ; Wed, 12 Aug 2020 15:06:10 -0700 (PDT) Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1k5yss-0004Bw-FS for gendispatch@ietf.org; Wed, 12 Aug 2020 15:06:10 -0700 Received: (qmail 11228 invoked from network); 12 Aug 2020 22:06:10 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.35.190]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Aug 2020 22:06:10 -0000 To: Fernando Gont , Brian E Carpenter , Nick Doty Cc: gendispatch@ietf.org References: <20200722163704.8ADB21D61A46@ary.qy> <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> <14018709-49ab-0cb8-343c-e4edbcde28ca@gmail.com> <6e2e232a-2565-c87a-9ead-f1ca23323224@si6networks.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <04c041ac-71bf-cad1-eb42-c47aab5448f8@huitema.net> Date: Wed, 12 Aug 2020 15:06:13 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <6e2e232a-2565-c87a-9ead-f1ca23323224@si6networks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.196.221 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.221/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.221/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0X2OOYwfFINEXkW0Te3GMuqpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDtLSXJfCfZOnWpXE1/I0nj9Xt FNSzkMWnDricnMrpFJrNtwot2xU+MuPi2GV9qH9hQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEFTr1kXHz+fWAZp3N0TEAHQ7GrRD93GuKsil0DsNlfaQNjS91 xLLHjz8tOnVewUzjKn6AaXxoL/FjeXc4guU5t5coTPkiAq+E/1gvF2d40ruQVyADaS6UpCBADjTx teudCa15Ytj/yAhGv8ezOASMHW/bWfgucjnNmABpGhD9TTsjQT2BGVI0EbGkW8Q42wJCdCZm6kTr qH+fmxyzQoG+NtezYqxGMqsKjARq8PBC4qjRn0hhkccum+xyb3k4eNalTAas0edmB2q/yBRqnQY9 Wp4oEuFb796V1/nl3YbqwU/VPb6Z51AWQAUvAUQbV3oqEaMjfjmXaBok2IyAEprch60jiD6XqsJZ tjQxlyCdsewdockuvmFY9cQ88McMLiJhycP4K1Fpu7HXiVspqMvyEDW/LCROJJYZ7JhenjA36IDo Oo70iqAlsD2ZyQe0MRcofppBlEHIo5xu8chHRfsZ1wRRiI4FYjmNWKK4C97xdQjTPpuFqUUQz+mM 8JAD4ECWrK59v5DHSYgsWR42p4iTFBzd1TBXbJNvBC1nKO3+wSNkf5pIJLXT7Z72xliDIHwIuqNy bYXcNZvG6GFCWOwYelFfEoXm0/FPF8PR0w363llawGp7uMayr58cbbCdMhttbscqRIE+6nhki2/N vhrDCXR6mMZiP8hyi9JD/oRrQtQcSyQwpbsYuxSOGTH6k0lfJmkP8s1HCfLKOW1F2ohPJ/AFMvX7 q8M4x6bP/gjzw0OgghQYwZVLClIproNi1WM01Bh4x4h9uYrmdPlyGg3lun80sIBTfGesZu6FzlJ8 P6r2OKHH5lr9xXvSM4nM3avg X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Gendispatch] draft-knodel-terminology-02 X-BeenThere: gendispatch@ietf.org 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: Wed, 12 Aug 2020 22:06:33 -0000 On 8/12/2020 8:28 AM, Fernando Gont wrote: > On 9/8/20 20:19, Brian E Carpenter wrote: > [...] >> >> Yes, but a blocklist/allowlist like the W3C's will not get very far in= >> the IETF's world of rough consensus. I think we have to be more subtle= =2E >> For example, words like "oppressive" and "inclusive" or "exclusionary"= >> are themselves value judgments and carry a certain amount of bias >> with them. You can clearly see that in the endless loop of discussion >> on the IETF main lits. I'd much rather we say "inappropriate" or >> "unprofessional" when defining our topic. > > Even more... they result in value-judgement discussions that somehow > ironically seem to mostly exclude what would be the most > affected/oppressed/excluded parties (so to speak). I think that Brian is pointing in the right direction. Words like "master-slave" or "black list" have been used in the past without intent to exclude people and without engaging in racial categorizations. Assigning motives a posteriori just alienates people. It is also clear that language is evolving. Continued use of these terms would become a cultural marker, making a statement that the IETF as a whole does not want to make. We are thus much more likely to gather consensus by stating that we want our communications to be professional and avoid inappropriate metaphors. -- Christian Huitema From nobody Wed Aug 12 16:25:21 2020 Return-Path: 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 D79D53A0D2B for ; Wed, 12 Aug 2020 16:25:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 UwgONj_lGXEu for ; Wed, 12 Aug 2020 16:25:18 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C86383A0CE0 for ; Wed, 12 Aug 2020 16:25:18 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id z20so1797855plo.6 for ; Wed, 12 Aug 2020 16:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=+ogS51s0Lban6Easog5cbjBT1eicKHHSsT6QTM2hhdI=; b=GOveJKpFgiHrxu/pB9PmoUhG9h8gXaG3QVeSXUAgXlRSI0tJKmkC5YAmknDEODKXbP n83w18J6upHANcC3BVXasBxin35da6C689pGu698PZwla3MYLwUknkIT2U93ERztWjPP hUz+OOnwcPN4qOqNZomxNpt2EjQ6UOVsTkLN0QCfwAABakbVT718nwIQRQl4S4f4CnwC 2a/N6dnfYgTGdtAT/UnOtl2MnId09A7/pI5TkOfJ+AZyGnhc/pb6Kxb8gB2TGP9OSmA5 VWHyTRM4MtLlMTbf9F19iO6kzN1axlTdJGu0gRj7w8Qs3TouRHjvnBMcR9qyAJyxaZOA cDNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+ogS51s0Lban6Easog5cbjBT1eicKHHSsT6QTM2hhdI=; b=hHT5K7Kg5DBMwUO90en4ocZsO0GFeFn3UgsNw/r2RDpQEgPEAsDO9nmUODMvdCwrd5 Oj20l6rU4WFBu8idsTC9+JuKOWnwib/3fk5TC6gcEDy0HBUaZckNVOa8pA+wSawdbIvT a2gpCi7pW8+9DNsnJuXvHwUek6szNqyi+CEOiP3pCnEu38EvPNGhJEKbELaZT9DnfDw9 VoY+tQGakP0Mt8Xus6+yPVeHTeLnhIzRv+7h+5NNtSvuVudgC5saNnqbQVSFwF5urej3 q1ignL1K+KCMHPdCfD5WwO4BguKHUq3qD+cL9Wl2bOuJpqDpeK8tY6xGjvOlV20y3rhr cvSQ== X-Gm-Message-State: AOAM533kiDfPZdaPICvMkuwwrA7r7GZucWPivXjipPr/e46qrxSg5Nfg 7UHK6GvkwT8WOK9AdjrRgVxVCdR1fH8= X-Google-Smtp-Source: ABdhPJxUvVpA+9VOl+AeuMzhLw8AXGPbHzRVTMio3m2L1AmYFJdB8ykQ2+KtrwG1NnuK+rhfOtiSTw== X-Received: by 2002:a17:902:e906:: with SMTP id k6mr1619594pld.41.1597274717393; Wed, 12 Aug 2020 16:25:17 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id w6sm3000528pgr.82.2020.08.12.16.25.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Aug 2020 16:25:16 -0700 (PDT) To: Pete Resnick , gendispatch@ietf.org References: <20200722163704.8ADB21D61A46@ary.qy> <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> <957a094c-dba8-ed24-74da-8bd865470d71@lounge.org> <80EE288E-8BA1-4993-9FAE-834DD55153B9@episteme.net> From: Brian E Carpenter Message-ID: <648dcfa6-80b7-7cad-c016-381dca13a424@gmail.com> Date: Thu, 13 Aug 2020 11:25:13 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <80EE288E-8BA1-4993-9FAE-834DD55153B9@episteme.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Gendispatch] draft-knodel-terminology-02 X-BeenThere: gendispatch@ietf.org 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: Wed, 12 Aug 2020 23:25:20 -0000 On 13-Aug-20 07:25, Pete Resnick wrote: > So, again, let's leave this topic alone until the interim. I thought that this was an IETF WG and WG decisions are taken on the mailing list, not in meetings. Depending on time zones, some of us will not be at the meeting. I do agree that most of the discussion so far has not been helpful. In terms of dispatching the draft (which I agree is *this* WG's main job) I would like to suggest that there is quite a variety of partially overlapping options: 1. Recommend that it be dropped from IETF consideration... 1.1. ...and referred to the Independent stream 1.2. ...and referred to the RFC Editor 1.3. ...and forgotten 2. Recommend that a WG on this topic be formed... 2.1. ...and asked to use the draft as a starting point 2.1. ...and asked to start a completely new draft 3. Recommend that a sponsoring AD be found... 3.1. ...and that the draft be used as a starting point 3.2. ...and that the AD solicits a completely new draft 4. Recommend that the issue be handled solely by the IESG 5. Recommend that the issue be handled solely by the RFC Editor I expect there are other options that I haven't thought of. Regards Brian From nobody Thu Aug 13 07:36:01 2020 Return-Path: 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 573193A0CB3 for ; Thu, 13 Aug 2020 07:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.onmicrosoft.com 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 carhoRxmcpLY for ; Thu, 13 Aug 2020 07:35:56 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100064.outbound.protection.outlook.com [40.107.10.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0D63A0CA2 for ; Thu, 13 Aug 2020 07:35:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VnfdFxmPUxtt3yFtgCloOZh8f2hlfoNI6bsHUqhNsqsbE9AwmLQcjWq4yaMdlkwJG1yNPprwaPvoGH/dapWy4XhFfVal35ptWV5ri7dIZd9fHtG4enOMYpKRVGtgNcmTCaHqyhT6wiFdZO2be7WbyG4G5LJ5sZSg+gw3/LeqFG2+5FlzGxT72KNFwDH+7TJq81pf5qyxbr9MQvorr1AAo1pZOowWBxW6Q1clFxJwu0gX7wQrLQjUjaRLir98vjkWDcioC9vw0CrU8bHghrZhqz+lZheiVoOu7/1RjCqHA2gP6EpRrS7AiEl1w7CZOZOo/OQwXKKovbQWYtCO3+7/Jw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L4LEX4Ykut6VPLyUBMMMtNs+scaVHd/9ULkI1454RbY=; b=diaq/xnSoHk3yY6yUl+NPFuYzQM83hmBtKG/UybGlAAUD5oQMCmMc3ZqXvTGdhcKKxDxXI7GKf29rGc4zl/4GFI1EhO7diJE+bS2GqKyzZ7SN4C5HGgiyVT6SSRb9OGSBY0FNJt9mxpB2WNFRVF4lREbhMvoSSwn7viMvCGPMqdIpU4ejovJk0dOaLKch8Ti45QOYOFo5oMWv/L33YBnONMFjcuHWJS708KT+SFtlLXh8uHFSRe6sSzf5Vi+hdFRUXJ/PAeh8cNm/8debSLyUUgzqeNXpPCIrA25hYkg/apnn3bcnwoxh1ujSRCxk74EuNekH8Ab2VpBJmLrOwDGXw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=L4LEX4Ykut6VPLyUBMMMtNs+scaVHd/9ULkI1454RbY=; b=O+D8VSI9Jc87yNUzsWYiaqqrTBAuCROm+Vj2ozZBqAEomi4UgiJ34AahXexQtCOYN6WMWYBPvpfWmYZdPwA6NSLrG546dsQkkLXCq9VMjCbFz/ZC7nOu5HdcWvFw4vYrRZqJwc+IOE/7PiKZ9EtGLR0u9PtxQli+It8pvIQZxpI= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:71::15) by LO3P265MB2218.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:10b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3283.16; Thu, 13 Aug 2020 14:35:48 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::91fb:af23:a084:10cf]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::91fb:af23:a084:10cf%7]) with mapi id 15.20.3261.025; Thu, 13 Aug 2020 14:35:48 +0000 From: Andrew Campling To: "gendispatch@ietf.org" Thread-Topic: Timing of Gendispatch Interim Thread-Index: AdZxfpFo5wCM9ZAdQSKrG8uDlKRGvA== Date: Thu, 13 Aug 2020 14:35:48 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=419.consulting; x-originating-ip: [2a00:23c4:a499:2e00:1ce2:701f:9809:79cd] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 305f5226-d006-4244-7a1c-08d83f962bd5 x-ms-traffictypediagnostic: LO3P265MB2218: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(346002)(39830400003)(376002)(396003)(136003)(3480700007)(55016002)(71200400001)(6916009)(33656002)(6506007)(86362001)(508600001)(52536014)(316002)(966005)(8936002)(9686003)(83380400001)(186003)(5660300002)(64756008)(66476007)(66556008)(7696005)(30864003)(44832011)(76116006)(2906002)(66446008)(8676002)(66946007)(46492007); DIR:OUT; SFP:1101; x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB0573901A444F0E6B8B0A2460C2430LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 305f5226-d006-4244-7a1c-08d83f962bd5 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2020 14:35:48.4690 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jVS5B+XqgGR2BR/591skcdRw7OWPuhV7XAAjbD15Novq9QXexjewsEW9G2Vtix7x+VPrHsMRSHZP/a9qabXxyV/pWlzoNhOeKNvOj0NZSiU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO3P265MB2218 Archived-At: Subject: [Gendispatch] Timing of Gendispatch Interim X-BeenThere: gendispatch@ietf.org 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: Thu, 13 Aug 2020 14:35:59 -0000 --_000_LO2P265MB0573901A444F0E6B8B0A2460C2430LO2P265MB0573GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 8/12/20 12:25 PM, Pete Resnick wrote: > As to draft-knodel-terminology: The initial discussion (which I ask you > to please hold until the interim, which Francesca and I will schedule > ASAP) is about how to dispatch the document. That will involve to some > degree talking about the whether it's worth pursuing the overall > endeavor, independent of the document itself, but please let's focus the > discussion toward the dispatch question primarily. With apologies if I've missed it but I can't see any reference to proposed = timing for the Gendispatch Interim where this discussion will take place? Andrew --_000_LO2P265MB0573901A444F0E6B8B0A2460C2430LO2P265MB0573GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
On 8/12/20 12:25 PM, Pete Resnick wrote:
> As to draft-knodel-terminology: The initial discussion (which I a= sk you
> to please hold until the interim, which Francesca and I will sche= dule
> ASAP) is about how to dispatch the document. That will involve to= some
> degree talking about the whether it's worth pursuing the overall =
> endeavor, independent of the document itself, but please let's fo= cus the
> discussion toward the dispatch question primarily.
 <= /div>
With apologies if I’ve missed it but I can’t see any refer= ence to proposed timing for the Gendispatch Interim where this discussion w= ill take place? 
 <= /div>
 <= /div>
Andrew
&nb= sp;
 <= /div> --_000_LO2P265MB0573901A444F0E6B8B0A2460C2430LO2P265MB0573GBRP_-- From nobody Thu Aug 13 08:26:03 2020 Return-Path: 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 1E08D3A0DA5 for ; Thu, 13 Aug 2020 08:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 6dtoc-vT3zcN for ; Thu, 13 Aug 2020 08:26:00 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 654C53A0DA0 for ; Thu, 13 Aug 2020 08:25:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id F27BBB866226; Thu, 13 Aug 2020 10:25:58 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWHFuY2rwaBF; Thu, 13 Aug 2020 10:25:58 -0500 (CDT) Received: from [172.16.1.6] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 2FCA6B86621D; Thu, 13 Aug 2020 10:25:58 -0500 (CDT) From: "Pete Resnick" To: "Brian E Carpenter" Cc: gendispatch@ietf.org Date: Thu, 13 Aug 2020 10:25:57 -0500 X-Mailer: MailMate (1.13.1r5699) Message-ID: <800630BB-522E-403D-ADDB-A5B9BBEAC0E4@episteme.net> In-Reply-To: <648dcfa6-80b7-7cad-c016-381dca13a424@gmail.com> References: <20200722163704.8ADB21D61A46@ary.qy> <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> <957a094c-dba8-ed24-74da-8bd865470d71@lounge.org> <80EE288E-8BA1-4993-9FAE-834DD55153B9@episteme.net> <648dcfa6-80b7-7cad-c016-381dca13a424@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Gendispatch] draft-knodel-terminology-02 X-BeenThere: gendispatch@ietf.org 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: Thu, 13 Aug 2020 15:26:02 -0000 On 12 Aug 2020, at 18:25, Brian E Carpenter wrote: > On 13-Aug-20 07:25, Pete Resnick wrote: > >> So, again, let's leave this topic alone until the interim. > > I thought that this was an IETF WG and WG decisions are taken > on the mailing list, not in meetings. They are. However, it is perfectly acceptable to delay some discussions until face-to-face or interim meetings and bring the results of such meetings back to the list for review and further discussion. > Depending on time zones, > some of us will not be at the meeting. I was considering holding more than one to address this concern. As soon as Francesca is back from holiday, I'll discuss with her and we'll send out a Doodle poll. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Thu Aug 13 08:26:21 2020 Return-Path: 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 BF7683A0DC1 for ; Thu, 13 Aug 2020 08:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 I2CVf2eI2Vlx for ; Thu, 13 Aug 2020 08:26:16 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA1D3A0DB6 for ; Thu, 13 Aug 2020 08:26:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 38468B866253; Thu, 13 Aug 2020 10:26:13 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKL07gLVnYgD; Thu, 13 Aug 2020 10:26:10 -0500 (CDT) Received: from [172.16.1.6] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id E66D1B866243; Thu, 13 Aug 2020 10:26:10 -0500 (CDT) From: "Pete Resnick" To: "Andrew Campling" Cc: gendispatch@ietf.org Date: Thu, 13 Aug 2020 10:22:58 -0500 X-Mailer: MailMate (1.13.1r5699) Message-ID: <7B481E0A-94E2-4B86-A85D-72BA75FA00C6@episteme.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_62F5BF84-1B85-4820-8C41-8AEF673B81AC_=" Embedded-HTML: [{"HTML":[498, 1286], "plain":[167, 627], "uuid":"8207A93D-3447-4F03-AFE5-C7319475FEDA"}] Archived-At: Subject: Re: [Gendispatch] Timing of Gendispatch Interim X-BeenThere: gendispatch@ietf.org 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: Thu, 13 Aug 2020 15:26:20 -0000 --=_MailMate_62F5BF84-1B85-4820-8C41-8AEF673B81AC_= Content-Type: text/plain; format=flowed Francesca is on holiday until the weekend, so I was holding off on sending out a Doodle poll until she's back. pr On 13 Aug 2020, at 9:35, Andrew Campling wrote: > On 8/12/20 12:25 PM, Pete Resnick wrote: >> As to draft-knodel-terminology: The initial discussion (which I ask >> you >> to please hold until the interim, which Francesca and I will schedule >> ASAP) is about how to dispatch the document. That will involve to >> some >> degree talking about the whether it's worth pursuing the overall >> endeavor, independent of the document itself, but please let's focus >> the >> discussion toward the dispatch question primarily. > > With apologies if I've missed it but I can't see any reference to > proposed timing for the Gendispatch Interim where this discussion will > take place? > > > Andrew -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best --=_MailMate_62F5BF84-1B85-4820-8C41-8AEF673B81AC_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= p dir=3D"auto">Francesca is on holiday until the weekend, so I was holdin= g off on sending out a Doodle poll until she's back.

pr

On 13 Aug 2020, at 9:35, Andrew Campling wrote:

On 8/12/20 12:25 PM, Pete Resnick wrote:
> As to draft-knodel-terminology: The initial discussion (which I= ask you
> to please hold until the interim, which Francesca and I will sc= hedule
> ASAP) is about how to dispatch the document. That will involve = to some
> degree talking about the whether it's worth pursuing the overal= l
> endeavor, independent of the document itself, but please let's = focus the
> discussion toward the dispatch question primarily.
=C2=A0
With apologies if I=E2=80=99ve missed it but I can=E2=80=99t see any= reference to proposed timing for the Gendispatch Interim where this disc= ussion will take place?=C2=A0
=C2=A0
=C2=A0
Andrew
=C2= =A0
=C2=A0


--
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

--=_MailMate_62F5BF84-1B85-4820-8C41-8AEF673B81AC_=-- From nobody Thu Aug 13 11:32:49 2020 Return-Path: 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 B4AAB3A0FB8 for ; Thu, 13 Aug 2020 11:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 wg5QiKKCPB_B for ; Thu, 13 Aug 2020 11:32:46 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68E413A0FB3 for ; Thu, 13 Aug 2020 11:32:46 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 69AD3D4B for ; Thu, 13 Aug 2020 14:32:45 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 13 Aug 2020 14:32:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=fm3; bh=VuRwNC BMtrEbL9ywxoiw6exqsSYJIWGu0+nqYpucUu8=; b=nh0lByECBTdCOpIyNnh87v /KVXCAduQ1zIIzcHaayM6gbuXIKBomZ+QujYkpANlX5QX3Oy9DfkRGR2ie7aFZ2O NPAQ6Z2huJTb0EPnkIQgplbiMucYULJtxXl5oOUeJl2v39L6SfYZu323U5v/qIMN vYIrCq+iqadLKwdya6K/lrRBDOtcdvhYjhfVs4j6pp2Xv7msuLCt5L1OS6L0ePbj lofU54tgTWVRWnQtfNgRebX3oyuF/cReBU1qnSYiax8ghdafUeytwB7TmvCL0KgR qoYyBbDhY1POx3ISAXAjy38MlLDAB+FxKTLTNj8ydhv/SJH3bTaDoRlhpykwkfzA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrleehgddutdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepveefteduieegtd elvddvtddufeejjeffvdefteejieeulefgtdfggedtffektedunecukfhppedutdekrddv vddurddukedtrdduheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id B9A5C3280063 for ; Thu, 13 Aug 2020 14:32:44 -0400 (EDT) To: gendispatch@ietf.org References: <20200722163704.8ADB21D61A46@ary.qy> <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> <957a094c-dba8-ed24-74da-8bd865470d71@lounge.org> <80EE288E-8BA1-4993-9FAE-834DD55153B9@episteme.net> <648dcfa6-80b7-7cad-c016-381dca13a424@gmail.com> <800630BB-522E-403D-ADDB-A5B9BBEAC0E4@episteme.net> From: Keith Moore Message-ID: <866a7d7a-255d-341a-eb5f-8504bc18e84e@network-heretics.com> Date: Thu, 13 Aug 2020 14:32:43 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <800630BB-522E-403D-ADDB-A5B9BBEAC0E4@episteme.net> Content-Type: multipart/alternative; boundary="------------CF923CA097C5CADD4F8DFF1B" Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] draft-knodel-terminology-02 X-BeenThere: gendispatch@ietf.org 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: Thu, 13 Aug 2020 18:32:48 -0000 This is a multi-part message in MIME format. --------------CF923CA097C5CADD4F8DFF1B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/13/20 11:25 AM, Pete Resnick wrote: >> I thought that this was an IETF WG and WG decisions are taken >> on the mailing list, not in meetings. > > They are. However, it is perfectly acceptable to delay some > discussions until face-to-face or interim meetings and bring the > results of such meetings back to the list for review and further > discussion. I emphatically disagree, for multiple reasons.  Deferring discussion to an interim meeting is just a way of sweeping the discussion under a rug, and making it more difficult for people to participate. And considering that we're witnessing repeated abusive behavior by the IETF leadership,  this is not a topic that should be deferred. Keith --------------CF923CA097C5CADD4F8DFF1B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/13/20 11:25 AM, Pete Resnick wrote:

I thought that this was an IETF WG and WG decisions are taken
on the mailing list, not in meetings.

They are. However, it is perfectly acceptable to delay some discussions until face-to-face or interim meetings and bring the results of such meetings back to the list for review and further discussion.

I emphatically disagree, for multiple reasons.  Deferring discussion to an interim meeting is just a way of sweeping the discussion under a rug, and making it more difficult for people to participate.

And considering that we're witnessing repeated abusive behavior by the IETF leadership,  this is not a topic that should be deferred.

Keith


--------------CF923CA097C5CADD4F8DFF1B-- From nobody Thu Aug 13 11:40:50 2020 Return-Path: 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 DFD133A104C for ; Thu, 13 Aug 2020 11:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 yraj1WlKXhrh for ; Thu, 13 Aug 2020 11:40:45 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF3BC3A1039 for ; Thu, 13 Aug 2020 11:40:45 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id D808AF57 for ; Thu, 13 Aug 2020 14:40:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 13 Aug 2020 14:40:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=L8Aoby BumlI08K1Us63il1HaeJa9GPz/qNGt9buteUM=; b=rE5vhMm5nV8eyNM90UD3L2 l0e81T3XUx1nf/nd7qszKQqgrjNF/pc2ss4DAbnPFwIoketS6J5Riv2BztOAKPkv nVgWz0bFPOQ7fzLQLc7Bhtia/fMTheHCgd/vsIm0LXunKfcLJRo8/IQ7ErRZDf4a PxK/gz6YOen5VllqV5zjKJeWSujALn0vNnQPRXVu/t9yDSGOm2Hp85chogQgPvw8 BR+HQZ0mvqH7R9o/h+KgxypOjbJSBieoNJN+ybElGK2AVVgrtUyDd33YnAF7DsSE uVCe0Mzhb9fmTmmvAQKIXhHYkjQemspsrcPQqKYytjuuSeyDBDhOf1Q6/boz0o0g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrleehgddutdefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefvhffukffffgggtgfgsehtkeertd dtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthifohhr khdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeetfeevhedufeelvd eikeefjedtvdehhfejhfdtheehfedvtdelgeeugfefuedtueenucfkphepuddtkedrvddv uddrudektddrudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 0A18F3280068 for ; Thu, 13 Aug 2020 14:40:43 -0400 (EDT) To: gendispatch@ietf.org From: Keith Moore Message-ID: <7830d008-0567-3071-7794-5463db4e7c77@network-heretics.com> Date: Thu, 13 Aug 2020 14:40:43 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Gendispatch] Withdrawal of my support for draft-knodel-terminology X-BeenThere: gendispatch@ietf.org 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: Thu, 13 Aug 2020 18:40:49 -0000 Several weeks ago I sent out an email in support of this document.   I now realize that this was a mistake.   With this message, I hope to correct that mistake.   I hereby withdraw my support for this document and urge that it be abandoned. Keith From nobody Thu Aug 13 15:13:15 2020 Return-Path: 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 023243A0857 for ; Thu, 13 Aug 2020 15:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 8W_tnX5rpFY7 for ; Thu, 13 Aug 2020 15:13:13 -0700 (PDT) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EACD53A084D for ; Thu, 13 Aug 2020 15:13:12 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id ep8so3419742pjb.3 for ; Thu, 13 Aug 2020 15:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=QKbHLX+VfE+NLgI8iueSeiVnAqb3xLZZMEj+rFRqpYQ=; b=SB2gytFsXc5kMliAseymfyKViJQB8qR+ajhxFqeDEyzFAKrL37PBlIZzsQHf3/hWAY GSLsjX+UfCuo9lmkFHafBvpxzup2arb4ZRITe6EEj0gdXKq6LBEjwhNWvMxiR0Bv9aAb ofL1CbnWK1aepFnclfTYOQhMDZzZBPFnVNCPUNZrrLsOGJTeeRa+XjpZjZ4whO/KSoV2 OPyMSwjQbouZr6iYnXB+Q+5moU1bkFkcEVTuOLq4hbAmKGoLZlPvbMV4dVXEbz9NcQnI NMhglS9UcmpoSDjJlmYKhcctfReQ/MWv+ofkh8M8j1GktWj54FM5opdDTGwrJIVv7SS/ f9uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QKbHLX+VfE+NLgI8iueSeiVnAqb3xLZZMEj+rFRqpYQ=; b=iPGk3TzQnkaicdCs7VjuwjHBCvKoVEMUpf+7Vo9VVhsjvHYCw9TxkLSp+2ms7oLgOh +djQaJORgQ2g4cPBR6tjT0ffyhXTnOMRRobxjrMOsYmhDNiZ8teFcaXaf+el2JtbPfAG WpRyG6FSY4meUpCamfHBpYa3FppQUtjELvceHar4E2f5krEtzmtP2J4PCewSVmwf01h0 /TlCLl1YuF04deci5sCvfjOzRwMsG5ftFWTordtd8bmsPOiP7FvgyCh3Dv02XhAwIWxY pUtjT3Egnd/dL/VFnW5x7XTAab5giiBAnYGUDgc7RGXT2qca4Sy+8lbcSoVqCUcY/ohW pg1g== X-Gm-Message-State: AOAM530QRnnf1vl30/Ks3WR3RCMHWEWCfERHEG+y23Cm1tj0iWYF4Zi7 ar+WJx4Br70p1poMNHquULoMew4Wbpk= X-Google-Smtp-Source: ABdhPJyHMOLprGvRZvBUbD5LuMiJCl5Qeud4lBu/1WCzveVF56xAZGB7pZ1ZSQySQT6vTrW1ofxK5A== X-Received: by 2002:a17:902:d20e:: with SMTP id t14mr5596590ply.327.1597356792017; Thu, 13 Aug 2020 15:13:12 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id r202sm6957819pfc.127.2020.08.13.15.13.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Aug 2020 15:13:11 -0700 (PDT) To: Keith Moore , gendispatch@ietf.org References: <7830d008-0567-3071-7794-5463db4e7c77@network-heretics.com> From: Brian E Carpenter Message-ID: <3dbce18a-9004-396b-d528-2b6da31791fc@gmail.com> Date: Fri, 14 Aug 2020 10:13:08 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <7830d008-0567-3071-7794-5463db4e7c77@network-heretics.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Gendispatch] Withdrawal of my support for draft-knodel-terminology X-BeenThere: gendispatch@ietf.org 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: Thu, 13 Aug 2020 22:13:14 -0000 I'm not going that far yet, but if the document is to progress, it will certainly need a lot of work on its stance and tone. Would the chairs welcome detailed reviews? Regards Brian Carpenter On 14-Aug-20 06:40, Keith Moore wrote: > Several weeks ago I sent out an email in support of this document.=C2=A0= =C2=A0 I=20 > now realize that this was a mistake.=C2=A0=C2=A0 With this message, I h= ope to=20 > correct that mistake.=C2=A0=C2=A0 I hereby withdraw my support for this= document=20 > and urge that it be abandoned. >=20 > Keith >=20 >=20 From nobody Thu Aug 13 16:41:52 2020 Return-Path: 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 6714F3A0B05; Thu, 13 Aug 2020 16:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.297 X-Spam-Level: X-Spam-Status: No, score=-0.297 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com 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 P4BeNcsjm50W; Thu, 13 Aug 2020 16:41:48 -0700 (PDT) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 317713A0B03; Thu, 13 Aug 2020 16:41:47 -0700 (PDT) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.163.243]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 07DNfYkN017601 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Aug 2020 16:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1597362106; x=1597448506; i=@elandsys.com; bh=dFGWFAq+PWWbilD0q0QBQkIISTsF2zhKJtKeXPv0nV4=; h=Date:To:From:Subject:In-Reply-To:References; b=uE8IxRk1pDOWBvdvustqRILdhilGLnv3QRbzNLCGMh6zaaB4LOoftbLt74QBiFP7x 5aBCNk59RGUR6D/TpXNt+RH5WUZFiv5eVeB4rtbdQuXOsVQJuuaDepgcQEV2r0nROA MWuMQZL0Wj39elHgXqrTe2bKY3zsbminNxw3HWes= Message-Id: <6.2.5.6.2.20200813163635.0aea3b00@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 13 Aug 2020 16:41:23 -0700 To: gendispatch-chairs@ietf.org, gendispatch@ietf.org From: S Moonesamy In-Reply-To: <80EE288E-8BA1-4993-9FAE-834DD55153B9@episteme.net> References: <20200722163704.8ADB21D61A46@ary.qy> <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> <957a094c-dba8-ed24-74da-8bd865470d71@lounge.org> <80EE288E-8BA1-4993-9FAE-834DD55153B9@episteme.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Gendispatch] draft-knodel-terminology-02 X-BeenThere: gendispatch@ietf.org 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: Thu, 13 Aug 2020 23:41:50 -0000 Dear General Area Dispatch Chairs, At 12:25 PM 12-08-2020, Pete Resnick wrote: >So, again, let's leave this topic alone until the interim. Does the above refers to the draft mentioned in the subject line? Was a decision taken at the last meeting of the working Group? If that is the case, who took the decision? Regards, S. Moonesamy From nobody Thu Aug 13 18:59:33 2020 Return-Path: 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 D664A3A0BFF for ; Thu, 13 Aug 2020 18:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, HEADER_FROM_DIFFERENT_DOMAINS=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=iecc.com header.b=o6NImaN8; dkim=pass (2048-bit key) header.d=taugh.com header.b=jWE1HzAp 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 ye2s8UDtq0Dm for ; Thu, 13 Aug 2020 18:59:30 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589543A0BF4 for ; Thu, 13 Aug 2020 18:59:29 -0700 (PDT) Received: (qmail 8084 invoked from network); 14 Aug 2020 01:59:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1f91.5f35f000.k2008; bh=0ezB4pCfvivDaXZqrerCgKIYUrFPPpTqOCpLHtY7+88=; b=o6NImaN8MoBu/GEInizGh98IDRGslH7/5h7ONT+cE6OaRGFjzuC1ygWxHc/wYx8zhEed9VFQ7gtHErwWuDw2V/ZoFhUmV2pW9U4AQNZlDgIkS2TeSrfrJg1LRHDX5GCnX2HPTZK7A7bxwYVRppuzfIOuaJUvSlDJCQTg+BLAtTJVVPs04iXBjwtIt8ibuEP4uCzmS8svX1+gHOkaTfzYCrfJC6UK6dLa7xdQsZSCdqvga32IXh6fY5u2L+8VIjIf2ClrdTmTSNdrwyUr82OdP+8b2k+cK7eeklOuvelhbJGi69VrhLcLRmovelboFFP4QOfqA4uXQbiFWaSxEYWljg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1f91.5f35f000.k2008; bh=0ezB4pCfvivDaXZqrerCgKIYUrFPPpTqOCpLHtY7+88=; b=jWE1HzApEpRw09DPPscHhFy+CMFIgc1YEFhcnhfLak4BwO6uGpSXmUfYTItYqozypvG68xawbHgQY3Wqn9110BNcsjnPbXI1TPxifnHjjPq+LUqiVyUXftkiAtW8T0fhV5o1lMUJKpYQoaIDJlgj7wiyB5uWclezHpn6X2hA/OE82Fq+EMGW4SiKfzFQnQJX7l6dX16xMGrrpkm+VPQmwK6ehLpabY4aJtf5cMbsqEmjBaSOj9nRfCnLZ26ttQQ3PefUhPrXN/fDxzhdzzYlVn7CcJtJnfMXh+WdlvethATPbAujbpQ4s17xa0X1G59oQM7p01iidUkG7YCKUWonhw== Received: from ary.local ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 14 Aug 2020 01:59:28 -0000 Received: by ary.local (Postfix, from userid 501) id 993B41E92DB9; Thu, 13 Aug 2020 21:59:27 -0400 (EDT) Date: 13 Aug 2020 21:59:27 -0400 Message-Id: <20200814015927.993B41E92DB9@ary.local> From: "John Levine" To: gendispatch@ietf.org In-Reply-To: <3dbce18a-9004-396b-d528-2b6da31791fc@gmail.com> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Gendispatch] Withdrawal of my support for draft-knodel-terminology X-BeenThere: gendispatch@ietf.org 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: Fri, 14 Aug 2020 01:59:32 -0000 In article <3dbce18a-9004-396b-d528-2b6da31791fc@gmail.com> you write: >I'm not going that far yet, but if the document is to progress, it will >certainly need a lot of work on its stance and tone. Would the chairs >welcome detailed reviews? I'm only in favor of adopting it as a placeholder to start a process. I described my reservations about its specific contents in a message I sent to this list a while ago. R's, John From nobody Thu Aug 13 19:05:12 2020 Return-Path: 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 DB03F3A0C06; Thu, 13 Aug 2020 19:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 Csru70c5g1NV; Thu, 13 Aug 2020 19:05:07 -0700 (PDT) Received: from eastern.birch.relay.mailchannels.net (eastern.birch.relay.mailchannels.net [23.83.209.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56FB3A0C04; Thu, 13 Aug 2020 19:05:06 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 01414100D31; Fri, 14 Aug 2020 02:05:06 +0000 (UTC) Received: from pdx1-sub0-mail-a88.g.dreamhost.com (100-96-23-22.trex.outbound.svc.cluster.local [100.96.23.22]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 38F5E101065; Fri, 14 Aug 2020 02:05:05 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a88.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Fri, 14 Aug 2020 02:05:05 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Harmony-Drop: 1ca705604f691896_1597370705471_4107106872 X-MC-Loop-Signature: 1597370705471:4198584252 X-MC-Ingress-Time: 1597370705471 Received: from pdx1-sub0-mail-a88.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a88.g.dreamhost.com (Postfix) with ESMTP id E7CB680C21; Thu, 13 Aug 2020 19:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=4J2ccHVOEtEXZ2 AUQdEEjevHQGw=; b=TVpMwkRSG7nysFzxvm+T1tOW7u6Ic80Pdfsf/bwH64zn8V owafqZ5IeFEyg7d0TqIYMCxEPpB+bi6CaeWtBSIgoLS0yqGu1CMALTkbbsVH9yIg jUOmuvok+OCw1QgmAvNbH32cjNxUM7jPoxNgBQeHLzv/j8zm94pl1DzD6oKLc= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 2F5F880C07; Thu, 13 Aug 2020 19:05:03 -0700 (PDT) Date: Thu, 13 Aug 2020 21:05:01 -0500 X-DH-BACKEND: pdx1-sub0-mail-a88 From: Nico Williams To: gendispatch@ietf.org Cc: ietf Message-ID: <20200814020459.GH3100@localhost> References: <9ABDC2BC-E6A3-4249-99C5-F0BB3683A03D@ietf.org> <6AA0BCBB-D95B-4036-B94D-5E79E7B94D75@ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6AA0BCBB-D95B-4036-B94D-5E79E7B94D75@ietf.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedrleeigdehgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [Gendispatch] Terminology discussion threads X-BeenThere: gendispatch@ietf.org 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: Fri, 14 Aug 2020 02:05:10 -0000 On Thu, Aug 13, 2020 at 09:48:30PM -0400, IETF Chair wrote: > I believe we wind up in this kind of situation over and over because > IETF participants have no shared norms about respecting each other or > demonstrating empathy towards one another. With no norms about > respecting one another as human beings, no value assigned to composing > thoughtful replies, and no expectation of simply treating each other > with kindness on the list, our discussions devolve into toxic, snarky, > knee-jerk back-and-forth. Without norms, processes like the one > established in RFC 3005 are not worth much. This is the least empathic message in all of this thread. Some of us have been quite polite, professional, and reasoned in our positions that do not support yours. We get no credit. Instead we see insinuations and bullying by the leadership and others. Nico -- From nobody Thu Aug 13 20:38:15 2020 Return-Path: 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 780483A0C93; Thu, 13 Aug 2020 20:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 jr0swFq_iwz2; Thu, 13 Aug 2020 20:38:08 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADFA83A0C8B; Thu, 13 Aug 2020 20:38:07 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BSTfh6sWnz1kH; Fri, 14 Aug 2020 05:38:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1597376284; bh=4qXnMJtj7ePCiIS18OnxDTLJb0ZzERxiGqd7/6OgltE=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=I4Tae1s8YQAevWTBwGctesaH1b0hwMH4JI0B0nwLT3CNQZQkwi2bIOdZjskTFdQCk tFLsoLKaWIxSLfyWRC3SP5A/6JvAdHkmOdG/jiFsjwCZiM55tWnCNwDwI9jGmOOBwz io22aPpCf7oe4+PyjzkbpP2kHmC+cC4IPEvNwrVg= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 8f0fZMYTozcy; Fri, 14 Aug 2020 05:38:04 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 14 Aug 2020 05:38:03 +0200 (CEST) Received: from [10.160.176.154] (199-7-157-47.eng.wind.ca [199.7.157.47]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 3E62C6029B99; Thu, 13 Aug 2020 23:38:02 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Paul Wouters Mime-Version: 1.0 (1.0) Date: Thu, 13 Aug 2020 23:37:52 -0400 Message-Id: References: <6AA0BCBB-D95B-4036-B94D-5E79E7B94D75@ietf.org> Cc: ietf In-Reply-To: <6AA0BCBB-D95B-4036-B94D-5E79E7B94D75@ietf.org> To: gendispatch@ietf.org X-Mailer: iPhone Mail (17G68) Archived-At: Subject: Re: [Gendispatch] Terminology discussion threads X-BeenThere: gendispatch@ietf.org 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: Fri, 14 Aug 2020 03:38:10 -0000 On Aug 13, 2020, at 23:26, IETF Chair wrote: >=20 > =EF=BB=BFHi all, >=20 > It=E2=80=99s clear from the list traffic today that the process described i= n my message below is unworkable because the interpretation of "substantive m= essage on this same topic=E2=80=9D is subjective rather than objective. My a= pologies for the mistake. I=E2=80=99ve asked the secretariat to unblock the t= hree threads listed below and restore Nadim Kobeissi=E2=80=99s posting privi= leges. Given time zones, I expect these changes will not take effect until Fri= day. Thanks for the message and the warning. The last few hours has seen a lot more toxic discussions from people who fee= l that they must be able to say anything =E2=80=9Cbecause freedom=E2=80=9D. Unfortunately that is exactly the behaviour that was the source of the probl= ems with this thread. I do not want to be on such a toxic list, even more so now that as a result o= f this IETF Chair action reversal, those people are further emboldened in th= eir Abu=E2=80=99s I=E2=80=99ve behaviour. I am now unsubscribing from the list. =20 Paul= From nobody Thu Aug 13 21:28:35 2020 Return-Path: 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 CAB8A3A0CD3; Thu, 13 Aug 2020 21:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 0jQ16vw4IZW7; Thu, 13 Aug 2020 21:28:33 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049433A0C55; Thu, 13 Aug 2020 21:28:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id A6B30B8793CB; Thu, 13 Aug 2020 23:28:26 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNAaNjKisS8n; Thu, 13 Aug 2020 23:28:15 -0500 (CDT) Received: from [172.16.1.6] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id C25BEB879363; Thu, 13 Aug 2020 23:28:15 -0500 (CDT) From: "Pete Resnick" To: "S Moonesamy" Cc: gendispatch-chairs@ietf.org, gendispatch@ietf.org Date: Thu, 13 Aug 2020 23:27:56 -0500 X-Mailer: MailMate (1.13.1r5704) Message-ID: In-Reply-To: <6.2.5.6.2.20200813163635.0aea3b00@elandnews.com> References: <20200722163704.8ADB21D61A46@ary.qy> <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> <957a094c-dba8-ed24-74da-8bd865470d71@lounge.org> <80EE288E-8BA1-4993-9FAE-834DD55153B9@episteme.net> <6.2.5.6.2.20200813163635.0aea3b00@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [Gendispatch] draft-knodel-terminology-02 X-BeenThere: gendispatch@ietf.org 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: Fri, 14 Aug 2020 04:28:35 -0000 On 13 Aug 2020, at 18:41, S Moonesamy wrote: > Dear General Area Dispatch Chairs, > At 12:25 PM 12-08-2020, Pete Resnick wrote: >> So, again, let's leave this topic alone until the interim. > > Does the above refers to the draft mentioned in the subject line? Yes, and the general subject of that draft: Since some of the possible outcomes we can suggest to dispatch the document include chartering a new WG or proposing a BOF, the draft itself may not survive the dispatch. > Was a decision taken at the last meeting of the working Group? As per the meeting minutes: https://www.ietf.org/proceedings/108/minutes/minutes-108-gendispatch-01 there was no final decision as to the desired dispatch, and a request was made for discussion to continue on the mailing list. Some of that discussion did take place, but after the blowup on the IETF mailing list, it seemed likely that the discussion on the list was likely to quickly turn unproductive until we had some time to sort things (virtually) face-to-face and bring some more substance back to the list. That's why I asked for a pause in the discussion here until we had a chance to schedule the interim(s). pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Thu Aug 13 21:43:25 2020 Return-Path: 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 8617A3A0CE1 for ; Thu, 13 Aug 2020 21:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JzEd7ZcGHUBN for ; Thu, 13 Aug 2020 21:43:19 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 005793A0CDF for ; Thu, 13 Aug 2020 21:43:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 0FFA8B87992F; Thu, 13 Aug 2020 23:43:18 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRcDfJq6xF1C; Thu, 13 Aug 2020 23:43:09 -0500 (CDT) Received: from [172.16.1.6] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id C07D4B87991E; Thu, 13 Aug 2020 23:43:09 -0500 (CDT) From: "Pete Resnick" To: "Keith Moore" Cc: gendispatch@ietf.org Date: Thu, 13 Aug 2020 23:41:38 -0500 X-Mailer: MailMate (1.13.1r5704) Message-ID: In-Reply-To: <866a7d7a-255d-341a-eb5f-8504bc18e84e@network-heretics.com> References: <20200722163704.8ADB21D61A46@ary.qy> <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> <957a094c-dba8-ed24-74da-8bd865470d71@lounge.org> <80EE288E-8BA1-4993-9FAE-834DD55153B9@episteme.net> <648dcfa6-80b7-7cad-c016-381dca13a424@gmail.com> <800630BB-522E-403D-ADDB-A5B9BBEAC0E4@episteme.net> <866a7d7a-255d-341a-eb5f-8504bc18e84e@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Gendispatch] draft-knodel-terminology-02 X-BeenThere: gendispatch@ietf.org 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: Fri, 14 Aug 2020 04:43:24 -0000 On 13 Aug 2020, at 13:32, Keith Moore wrote: > Deferring discussion to an interim meeting is just a way of sweeping > the discussion under a rug, and making it more difficult for people to > participate. I will certainly not let discussion of this document/topic be swept under the rug. My intention is to have some discussion at the interim(s) that will produce some clear guidance to discussion on the list. I will try to work with Francesca to see if it's logistically possible to have more than one interim so that it is a bit easier for people to participate. Once we've complete the interim(s), I hope that the guidance we come up with can make the list discussion much more focused than it otherwise would have been, and we can finally come to a dispatch decision. So unless Francesca and I do our jobs poorly, I believe that the discussion will neither be swept under the rug or more difficult to participate in. > And considering that we're witnessing repeated abusive behavior by the > IETF leadership,  this is not a topic that should be deferred. Abusive behavior by IETF leadership is *definitely* not a topic for this list. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Thu Aug 13 21:59:03 2020 Return-Path: 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 29E6F3A0CE5 for ; Thu, 13 Aug 2020 21:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 7pss72DCTC_6 for ; Thu, 13 Aug 2020 21:59:00 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A38B73A0C68 for ; Thu, 13 Aug 2020 21:59:00 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id B33ACFDF; Fri, 14 Aug 2020 00:58:59 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 14 Aug 2020 00:58:59 -0400 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=fm3; bh=uPegSg 3NcQejZ7BS2TRWIyUKn31mjvUcCVPnTXzqwvk=; b=dbQVPryGH4u5FNm4DDdPpG 6VdARkUHOQbvN9E31G8zf+492ogkAamOlalBB6GzDGsp9o298ivBAUwNLb09kZMa s7EPXKCl0kJyKNME/5iiOYFc5NPrpBdNuIVAUduq1oxDn53AQtanotVy1HLJM7bT BRnMIKm7jFyYhESIIWU/6I5E/CSPKfL6pkoTP71vxpvvOqcxfbO/Yv+KuY0oPEQG 1QYTUpr8e4nT0Umm2UWGGlnyu2z/O65r1xv+pMfdeAHLiU7h2T16+9YHHVUZiswW nhk0CzpWpSc4wqTxh+RcZ76gIEEC3oUnW/Jm9r2E9oBCBkk+4dfouRzvWLmFaQhA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrleeigdeltdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgesrgdtreertdefjeenucfhrhhomhepmfgvihhthhcu ofhoohhrvgcuoehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomheqne cuggftrfgrthhtvghrnhepveefteduieegtdelvddvtddufeejjeffvdefteejieeulefg tdfggedtffektedunecukfhppedutdekrddvvddurddukedtrdduheenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomh X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id BBCAD328005D; Fri, 14 Aug 2020 00:58:58 -0400 (EDT) To: Pete Resnick Cc: gendispatch@ietf.org References: <20200722163704.8ADB21D61A46@ary.qy> <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> <957a094c-dba8-ed24-74da-8bd865470d71@lounge.org> <80EE288E-8BA1-4993-9FAE-834DD55153B9@episteme.net> <648dcfa6-80b7-7cad-c016-381dca13a424@gmail.com> <800630BB-522E-403D-ADDB-A5B9BBEAC0E4@episteme.net> <866a7d7a-255d-341a-eb5f-8504bc18e84e@network-heretics.com> From: Keith Moore Message-ID: Date: Fri, 14 Aug 2020 00:58:57 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------ACC16EF0F0F4069589B699BC" Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] draft-knodel-terminology-02 X-BeenThere: gendispatch@ietf.org 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: Fri, 14 Aug 2020 04:59:02 -0000 This is a multi-part message in MIME format. --------------ACC16EF0F0F4069589B699BC Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/14/20 12:41 AM, Pete Resnick wrote: > >> Deferring discussion to an interim meeting is just a way of sweeping >> the discussion under a rug, and making it more difficult for people >> to participate. > > I will certainly not let discussion of this document/topic be swept > under the rug. My intention is to have some discussion at the > interim(s) that will produce some clear guidance to discussion on the > list. I will try to work with Francesca to see if it's logistically > possible to have more than one interim so that it is a bit easier for > people to participate. Once we've complete the interim(s), I hope that > the guidance we come up with can make the list discussion much more > focused than it otherwise would have been, and we can finally come to > a dispatch decision. So unless Francesca and I do our jobs poorly, I > believe that the discussion will neither be swept under the rug or > more difficult to participate in. Having thought about this a bit more, I realize that I'm concerned about several things: 1. Meetings raise the bar for participation, relative to email discussion, even if there are multiple meetings.   Multiple meetings might even raise the bar in some sense if some participants felt it necessary to attend more than one of them in order to not be left out of the loop.    (After all one of the features of usual meetings is that everyone is in the same room and everything can be put on the table; multiple meetings might actually defeat this.)   Meetings may also conflict with other things in one's life so it's not always possible to participate. Either way, practically speaking, when the _only_ way to participate is via a meeting, this has the likely effect of excluding people and reducing participation. 2. Meetings are necessarily short in duration.   While they do provide the opportunity for more rapid interaction, they also restrict people's ability to speak even when they are present. 3. Email list discussion, messy and uncomfortable though it can be, provides an opportunity for participants to refine their positions based on feedback from others, which is valuable. I understand that perhaps the gendispatch list is not the place for this discussion - it is a dispatch group after all - but perhaps a separate list should be created for this.   Deferring discussion to an interim meeting seems likely to have a chilling effect, and to further exacerbate the tensions that already exist. Keith --------------ACC16EF0F0F4069589B699BC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/14/20 12:41 AM, Pete Resnick wrote:


Deferring discussion to an interim meeting is just a way of sweeping the discussion under a rug, and making it more difficult for people to participate.

I will certainly not let discussion of this document/topic be swept under the rug. My intention is to have some discussion at the interim(s) that will produce some clear guidance to discussion on the list. I will try to work with Francesca to see if it's logistically possible to have more than one interim so that it is a bit easier for people to participate. Once we've complete the interim(s), I hope that the guidance we come up with can make the list discussion much more focused than it otherwise would have been, and we can finally come to a dispatch decision. So unless Francesca and I do our jobs poorly, I believe that the discussion will neither be swept under the rug or more difficult to participate in.

Having thought about this a bit more, I realize that I'm concerned about several things:

1. Meetings raise the bar for participation, relative to email discussion, even if there are multiple meetings.   Multiple meetings might even raise the bar in some sense if some participants felt it necessary to attend more than one of them in order to not be left out of the loop.    (After all one of the features of usual meetings is that everyone is in the same room and everything can be put on the table; multiple meetings might actually defeat this.)   Meetings may also conflict with other things in one's life so it's not always possible to participate.   Either way, practically speaking, when the _only_ way to participate is via a meeting, this has the likely effect of excluding people and reducing participation.

2. Meetings are necessarily short in duration.   While they do provide the opportunity for more rapid interaction, they also restrict people's ability to speak even when they are present.

3. Email list discussion, messy and uncomfortable though it can be, provides an opportunity for participants to refine their positions based on feedback from others, which is valuable.

I understand that perhaps the gendispatch list is not the place for this discussion - it is a dispatch group after all - but perhaps a separate list should be created for this.   Deferring discussion to an interim meeting seems likely to have a chilling effect, and to further exacerbate the tensions that already exist.

Keith


--------------ACC16EF0F0F4069589B699BC-- From nobody Thu Aug 13 22:14:55 2020 Return-Path: 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 D05723A0D2B for ; Thu, 13 Aug 2020 22:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 pQg0_Iaiq1iS for ; Thu, 13 Aug 2020 22:14:52 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6633A0D2A for ; Thu, 13 Aug 2020 22:14:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 02E16B87A48D; Fri, 14 Aug 2020 00:14:48 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p02Upm72dtW1; Fri, 14 Aug 2020 00:14:46 -0500 (CDT) Received: from [172.16.1.6] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 6289CB87A480; Fri, 14 Aug 2020 00:14:46 -0500 (CDT) From: "Pete Resnick" To: "Keith Moore" Cc: gendispatch@ietf.org Date: Fri, 14 Aug 2020 00:14:44 -0500 X-Mailer: MailMate (1.13.1r5704) Message-ID: <53103CD5-7128-4AF7-9EEF-996857664A63@episteme.net> In-Reply-To: References: <20200722163704.8ADB21D61A46@ary.qy> <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> <957a094c-dba8-ed24-74da-8bd865470d71@lounge.org> <80EE288E-8BA1-4993-9FAE-834DD55153B9@episteme.net> <648dcfa6-80b7-7cad-c016-381dca13a424@gmail.com> <800630BB-522E-403D-ADDB-A5B9BBEAC0E4@episteme.net> <866a7d7a-255d-341a-eb5f-8504bc18e84e@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Gendispatch] draft-knodel-terminology-02 X-BeenThere: gendispatch@ietf.org 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: Fri, 14 Aug 2020 05:14:54 -0000 Answering the last bit first: On 13 Aug 2020, at 23:58, Keith Moore wrote: > I understand that perhaps the gendispatch list is not the place for > this discussion - it is a dispatch group after all - but perhaps a > separate list should be created for this. This seems to me a chicken and egg problem: The purpose of a dispatch group is to recommend a place for further work to take place on a subject. Suggesting that we set up a separate list is certainly among our choices. But in order to come to that (or another) conclusion, we will have to have some discussion that I believe will become too contentious to have on this list. > Deferring discussion to an interim meeting seems likely to have a > chilling > effect, and to further exacerbate the tensions that already exist. I'm hoping that a 2-week-plus-a-few-days deferral will not exacerbate tensions. In fact, I suspect it will calm things a bit. > Having thought about this a bit more, I realize that I'm concerned > about several things: > > 1. Meetings raise the bar for participation, relative to email > discussion, even if there are multiple meetings. I certainly agree with that, along with your stated reasons, and it will definitely be the chairs' responsibility to make sure that the discussion on the list after the meeting(s) is full and inclusive. However: > Either way, practically speaking, when the _only_ way to participate > is via a meeting, this has the likely effect of excluding people and > reducing participation. My point is (and was in my previous message) that the meeting(s) will definitely *not* be the only way to participate. The meeting(s) will provide input to the list discussion, not replace it. I know sometimes in the IETF we forget that. I'm committing that the chairs will not. > 2. Meetings are necessarily short in duration.   While they do > provide the opportunity for more rapid interaction, they also restrict > people's ability to speak even when they are present. If we are unable to have a reasonably non-restrictive conversation on a single topic in a 1-2 hour meeting (hopefully twice), then your chairs are not doing a good job. > 3. Email list discussion, messy and uncomfortable though it can be, > provides an opportunity for participants to refine their positions > based on feedback from others, which is valuable. Agreed, and if we were going to eliminate email discussion completely, this would be a problem. But again, that is not the plan. What is being requested is a short delay (a bit more than a couple of weeks), some meeting time to sort some of the issues, and then a focused list discussion to do the dispatching. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Thu Aug 13 22:20:24 2020 Return-Path: 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 DAE553A0D25 for ; Thu, 13 Aug 2020 22:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 ZUUgPY2NQlxb for ; Thu, 13 Aug 2020 22:20:21 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB9FE3A0C6B for ; Thu, 13 Aug 2020 22:20:21 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id CC275539; Fri, 14 Aug 2020 01:20:20 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 14 Aug 2020 01:20:20 -0400 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=fm3; bh=B65Kxm 3KWG4SBVazEVW998M/qV4RPZovFyg5vjlCLnk=; b=jMfjizVZdGiOadXDhBIvd8 14d9kRl72XhxVyl53riMgzDiIvfz2dPop3CiEc3I5qwZRrqA6r57/Ay0z3xCW+Q6 /StXCJsikpw3PK5qbeOCsTxix4P56lu5Tw9OhpVEs3SNGoQfnTo4eMFOY3/DR+Kd I9Y5G1+Xz6S1ArDCGfnoLa2huU9w1AOQLRXn3CoN8NjhgeDTnv2IZ7o3lw/42EYw NAilnVzJSC5z3PW8Z3S7SGnvwVYejRkknUBQ+DkFvHzhwTDlV9E1K/E66juOpXjL 2N24tgGx9mCBCgEM8136V8VdM4Bpb2miJYYaEE5cUa5Ya6TYr4R7llTtCw51BZPQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrleeigdelhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefuvfhfhffkffgfgggjtgesrgdtreertdefjeenucfhrhhomhepmfgvihhthhcu ofhoohhrvgcuoehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomheqne cuggftrfgrthhtvghrnhepveefteduieegtdelvddvtddufeejjeffvdefteejieeulefg tdfggedtffektedunecukfhppedutdekrddvvddurddukedtrdduheenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomh X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id CAFF23280060; Fri, 14 Aug 2020 01:20:19 -0400 (EDT) To: Pete Resnick Cc: gendispatch@ietf.org References: <20200722163704.8ADB21D61A46@ary.qy> <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> <957a094c-dba8-ed24-74da-8bd865470d71@lounge.org> <80EE288E-8BA1-4993-9FAE-834DD55153B9@episteme.net> <648dcfa6-80b7-7cad-c016-381dca13a424@gmail.com> <800630BB-522E-403D-ADDB-A5B9BBEAC0E4@episteme.net> <866a7d7a-255d-341a-eb5f-8504bc18e84e@network-heretics.com> <53103CD5-7128-4AF7-9EEF-996857664A63@episteme.net> From: Keith Moore Message-ID: Date: Fri, 14 Aug 2020 01:20:18 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <53103CD5-7128-4AF7-9EEF-996857664A63@episteme.net> Content-Type: multipart/alternative; boundary="------------0A08A77F20AF07CCD2D0D427" Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] draft-knodel-terminology-02 X-BeenThere: gendispatch@ietf.org 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: Fri, 14 Aug 2020 05:20:23 -0000 This is a multi-part message in MIME format. --------------0A08A77F20AF07CCD2D0D427 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/14/20 1:14 AM, Pete Resnick wrote: >> >> 1. Meetings raise the bar for participation, relative to email >> discussion, even if there are multiple meetings. > > I certainly agree with that, along with your stated reasons, and it > will definitely be the chairs' responsibility to make sure that the > discussion on the list after the meeting(s) is full and inclusive. Well, that's not the normal way IETF does things, and I struggle to think of any other time in my 30 year history with IETF, when participants have been told to NOT post to a mailing list until a meeting is held. It makes me wonder if the idea is to try to use the meeting as a way to control or restrict the subsequent discussion.   And even if the context shouldn't be discussed here, it's hard to ignore it. Keith --------------0A08A77F20AF07CCD2D0D427 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/14/20 1:14 AM, Pete Resnick wrote:


1. Meetings raise the bar for participation, relative to email discussion, even if there are multiple meetings.

I certainly agree with that, along with your stated reasons, and it will definitely be the chairs' responsibility to make sure that the discussion on the list after the meeting(s) is full and inclusive.

Well, that's not the normal way IETF does things, and I struggle to think of any other time in my 30 year history with IETF, when participants have been told to NOT post to a mailing list until a meeting is held.

It makes me wonder if the idea is to try to use the meeting as a way to control or restrict the subsequent discussion.   And even if the context shouldn't be discussed here, it's hard to ignore it.

Keith


--------------0A08A77F20AF07CCD2D0D427-- From nobody Thu Aug 13 22:47:09 2020 Return-Path: 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 D36AA3A0D4D for ; Thu, 13 Aug 2020 22:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JvYCKutTKqGN for ; Thu, 13 Aug 2020 22:47:06 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E0CB3A0D46 for ; Thu, 13 Aug 2020 22:47:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id CFE64B87AFF9; Fri, 14 Aug 2020 00:47:04 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2o_jIXgT2Q9l; Fri, 14 Aug 2020 00:47:04 -0500 (CDT) Received: from [172.16.1.6] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id DA501B87AFF0; Fri, 14 Aug 2020 00:47:03 -0500 (CDT) From: "Pete Resnick" To: "Keith Moore" Cc: gendispatch@ietf.org Date: Fri, 14 Aug 2020 00:47:03 -0500 X-Mailer: MailMate (1.13.1r5704) Message-ID: <9F6BB155-E94E-4908-A4C7-3E977804E110@episteme.net> In-Reply-To: References: <20200722163704.8ADB21D61A46@ary.qy> <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> <957a094c-dba8-ed24-74da-8bd865470d71@lounge.org> <80EE288E-8BA1-4993-9FAE-834DD55153B9@episteme.net> <648dcfa6-80b7-7cad-c016-381dca13a424@gmail.com> <800630BB-522E-403D-ADDB-A5B9BBEAC0E4@episteme.net> <866a7d7a-255d-341a-eb5f-8504bc18e84e@network-heretics.com> <53103CD5-7128-4AF7-9EEF-996857664A63@episteme.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Gendispatch] draft-knodel-terminology-02 X-BeenThere: gendispatch@ietf.org 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: Fri, 14 Aug 2020 05:47:08 -0000 On 14 Aug 2020, at 0:20, Keith Moore wrote: > Well, that's not the normal way IETF does things, and I struggle to > think of any other time in my 30 year history with IETF, when > participants have been told to NOT post to a mailing list until a > meeting is held. I am quite sure I've heard chairs say in the past, "We're spinning our wheels on this topic. We're meeting at the f2f in a few weeks; let's put it on the agenda and hold off until we can discuss in person." And we've participated in a lot of WGs together. And to be clear: "asked", not "told". As per my message: "As to draft-knodel-terminology: The initial discussion (which I ask you to please hold until the interim, which Francesca and I will schedule ASAP) is about how to dispatch the document." Perhaps the second statement was a bit stronger: "So, again, let's leave this topic alone until the interim." But still, other than the topics that I said were out of scope of the WG (the merits of the IESG statement, the commentary on tone and style, the definition of "racism"), this was an (admittedly strong) request of one of the chairs, not an order. The latter isn't in my job description (or so I've been told). > It makes me wonder if the idea is to try to use the meeting as a way > to control or restrict the subsequent discussion.   And even if the > context shouldn't be discussed here, it's hard to ignore it. I can only speak for myself and say there were no such motives on my part. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Thu Aug 13 22:50:06 2020 Return-Path: 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 991793A0D54 for ; Thu, 13 Aug 2020 22:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 7I8AkINv9f8M for ; Thu, 13 Aug 2020 22:50:04 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 631343A0D52 for ; Thu, 13 Aug 2020 22:50:04 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 7E682AC2; Fri, 14 Aug 2020 01:50:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 14 Aug 2020 01:50:03 -0400 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=fm3; bh=TKCe+WKblnjkkkmy2ljuAycTWoQIVktn0btXYAXUX IE=; b=jXWOiP3PRY5Pt/Yy/UOV2twDyVCYJjA9GNek/iNUk2p9SuFsTpQh1OPb9 5oejRigUDfnihZB8RYpoHs4cKaV98bnnIp+xIK4/iKCHozEaWhPHSbrIy+Dfi1b2 osHB95C35lELgeLDpSjZmQ+pu3tvMofMz5cKE4Exp0NQD3tgcs8E1+9MTmaf65v+ RmADj2jP6UN3ZwXSevvp7RBLHzQSI7Fz8x0vpshMBlBvQLIANwnj4ytuq9lqjmUH cBjAOIvb/DYkcYUHgKjg2A8R8J2LayxSNslrwDmnUceHwnUOyQnBtAaEf65GkKYC oLF7h8ozBtVI0UcNjaQY4tKtUwrfw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrleeigddutdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomhepmfgvihht hhcuofhoohhrvgcuoehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh eqnecuggftrfgrthhtvghrnhephefhuedtheefgfefgffhkeehgfeugfeiudeugeejkeef leelueeiffetfeeuudeunecukfhppedutdekrddvvddurddukedtrdduheenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmohhorhgvsehnvght fihorhhkqdhhvghrvghtihgtshdrtghomh X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 60DFD3280059; Fri, 14 Aug 2020 01:50:02 -0400 (EDT) To: Pete Resnick Cc: gendispatch@ietf.org References: <20200722163704.8ADB21D61A46@ary.qy> <87AF7F28-98A8-4406-B20D-76570078B6EF@ischool.berkeley.edu> <957a094c-dba8-ed24-74da-8bd865470d71@lounge.org> <80EE288E-8BA1-4993-9FAE-834DD55153B9@episteme.net> <648dcfa6-80b7-7cad-c016-381dca13a424@gmail.com> <800630BB-522E-403D-ADDB-A5B9BBEAC0E4@episteme.net> <866a7d7a-255d-341a-eb5f-8504bc18e84e@network-heretics.com> <53103CD5-7128-4AF7-9EEF-996857664A63@episteme.net> <9F6BB155-E94E-4908-A4C7-3E977804E110@episteme.net> From: Keith Moore Message-ID: Date: Fri, 14 Aug 2020 01:50:01 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <9F6BB155-E94E-4908-A4C7-3E977804E110@episteme.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] draft-knodel-terminology-02 X-BeenThere: gendispatch@ietf.org 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: Fri, 14 Aug 2020 05:50:06 -0000 On 8/14/20 1:47 AM, Pete Resnick wrote: > On 14 Aug 2020, at 0:20, Keith Moore wrote: > >> Well, that's not the normal way IETF does things, and I struggle to >> think of any other time in my 30 year history with IETF, when >> participants have been told to NOT post to a mailing list until a >> meeting is held. > > I am quite sure I've heard chairs say in the past, "We're spinning our > wheels on this topic. We're meeting at the f2f in a few weeks; let's > put it on the agenda and hold off until we can discuss in person." And > we've participated in a lot of WGs together. > > And to be clear: "asked", not "told". As per my message: > > "As to draft-knodel-terminology: The initial discussion (which I ask > you to please hold until the interim, which Francesca and I will > schedule ASAP) is about how to dispatch the document." > > Perhaps the second statement was a bit stronger: > > "So, again, let's leave this topic alone until the interim." > > But still, other than the topics that I said were out of scope of the > WG (the merits of the IESG statement, the commentary on tone and > style, the definition of "racism"), this was an (admittedly strong) > request of one of the chairs, not an order. The latter isn't in my job > description (or so I've been told). > >> It makes me wonder if the idea is to try to use the meeting as a way >> to control or restrict the subsequent discussion.   And even if the >> context shouldn't be discussed here, it's hard to ignore it. > > I can only speak for myself and say there were no such motives on my > part. Thanks for your response.  I suppose we could all use a bit of a break.   I'm sure it will be an interesting meeting. Keith From nobody Fri Aug 14 09:45:29 2020 Return-Path: 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 92D603A0E41 for ; Fri, 14 Aug 2020 09:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.com 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 OBdsHCNO9hDe for ; Fri, 14 Aug 2020 09:45:23 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF0453A0E3F for ; Fri, 14 Aug 2020 09:45:21 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id g6so10561220ljn.11 for ; Fri, 14 Aug 2020 09:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tAaXHUul7ReDl5Pe2PX9TZ2bMO0SZotuog3GT4+a8b0=; b=sSWywyTVn09/T2dAAT+tNSPAXcXMU99f6OOrClSbmVh0cLa148tdgPhqtkZB/lMQzc /eO77cVNDN0y7Qj9xjjSYvtNewNDVjQ8hf+7U9UtKSvUohyKYEZa1vFSYKEeLYtvN+0k zZ+8s1C3w7jJwvJzHBKF9AP5BsPTjU2+5iWEW/y3VQlfxtX4Cw4E8TAhQohya2EQmdCv aEbRM5gTMtwborgSBiu9nG5xRZEsJCL3kh5b4aU7FRX2+IodX1Pdvkz8pt8c1dq3xQy+ 0s+C8kUmxaTmO1b+Oqo9WSgqZwBWKLPipJUc8l1Pl3zSBBXdah4DsBwM3qB6/PyVcK+e zmrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tAaXHUul7ReDl5Pe2PX9TZ2bMO0SZotuog3GT4+a8b0=; b=NgmjHMco7r3NYuTztSsAHKf6V9Yqm7Ou8s9ahkCQ9ox/TymryhTHTe30Fx5vk6H10l KETDaDmhEBp+LR2RmzM5jqdFk/QprlV5rYSSOFKdmpqzAAPffKxz6MJuQ+YdN7gwCihW Fox+AKReHPQpLXcF8RmRQ7y2MMzyJcsbpSyPPKmYOOTO6Ng79mYnGNYy12N16ZOqQci1 eiOEBCAqb9dVcHijL2hvGYuK4+RCUn1QSUfzT3mGjyVLNwwJVoLLK7yF1QLAXtt0mcfA 1j+cEwLyHk35WG3HFJAXKfbsy186q427nJqip9aeSCts/ektw99SGsUoWjox1ilOO5TW EtsQ== X-Gm-Message-State: AOAM531+repLHkezt5eryv4o2azqs7ZgWybr2PxvPyUSRTTWNulWnWbN 9LXbu3RIjTUHBoklH9+Lfe05n5RKWGHDBQNXE83EHw== X-Google-Smtp-Source: ABdhPJw4oO+v324iod9jjVwIhGLobeYA3UxrNhDG60oaP3ZF5KUKC8OMLNBvI0v0Gzp6Xqo4Tb3QuHQ9+w94eBxrd1U= X-Received: by 2002:a2e:9b4a:: with SMTP id o10mr1738582ljj.199.1597423519976; Fri, 14 Aug 2020 09:45:19 -0700 (PDT) MIME-Version: 1.0 References: <6AA0BCBB-D95B-4036-B94D-5E79E7B94D75@ietf.org> In-Reply-To: From: Eric Rescorla Date: Fri, 14 Aug 2020 09:44:43 -0700 Message-ID: To: Paul Wouters Cc: gendispatch@ietf.org, ietf Content-Type: multipart/alternative; boundary="00000000000076e66d05acd92588" Archived-At: Subject: Re: [Gendispatch] Terminology discussion threads X-BeenThere: gendispatch@ietf.org 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: Fri, 14 Aug 2020 16:45:26 -0000 --00000000000076e66d05acd92588 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Paul. Well, said. Despite the long history of the IETF discussion list being awful, I've felt an obligation to stay on it. However, it has now become so bad that I can longer do so. I would like to thank the IESG for creating the last call list so that it is still possible to participate in the business of the IETF without being part of this toxic environment. I'll see you there and in the WGs. -Ekr On Thu, Aug 13, 2020 at 8:38 PM Paul Wouters wrote: > On Aug 13, 2020, at 23:26, IETF Chair wrote: > > > > =EF=BB=BFHi all, > > > > It=E2=80=99s clear from the list traffic today that the process describ= ed in my > message below is unworkable because the interpretation of "substantive > message on this same topic=E2=80=9D is subjective rather than objective. = My > apologies for the mistake. I=E2=80=99ve asked the secretariat to unblock = the three > threads listed below and restore Nadim Kobeissi=E2=80=99s posting privile= ges. Given > time zones, I expect these changes will not take effect until Friday. > > Thanks for the message and the warning. > > The last few hours has seen a lot more toxic discussions from people who > feel that they must be able to say anything =E2=80=9Cbecause freedom=E2= =80=9D. > > Unfortunately that is exactly the behaviour that was the source of the > problems with this thread. > > I do not want to be on such a toxic list, even more so now that as a > result of this IETF Chair action reversal, those people are further > emboldened in their Abu=E2=80=99s I=E2=80=99ve behaviour. > > I am now unsubscribing from the list. > > Paul > --00000000000076e66d05acd92588 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Paul. Well, said.

Despite t= he long history of the IETF discussion list being awful, I've
felt a= n obligation to stay on it. However, it has now become so bad
that I can= longer do so.

I would like to thank the IESG for creating the last = call list so
that it is still possible to participate in the business of= the IETF
without being part of this toxic environment. I'll see you= there
and in the WGs.

-Ekr



On Thu, Aug 13, 2020 at 8:= 38 PM Paul Wouters <paul@nohats.ca= > wrote:
On A= ug 13, 2020, at 23:26, IETF Chair <chair@ietf.org> wrote:
>
> =EF=BB=BFHi all,
>
> It=E2=80=99s clear from the list traffic today that the process descri= bed in my message below is unworkable because the interpretation of "s= ubstantive message on this same topic=E2=80=9D is subjective rather than ob= jective. My apologies for the mistake. I=E2=80=99ve asked the secretariat t= o unblock the three threads listed below and restore Nadim Kobeissi=E2=80= =99s posting privileges. Given time zones, I expect these changes will not = take effect until Friday.

Thanks for the message and the warning.

The last few hours has seen a lot more toxic discussions from people who fe= el that they must be able to say anything =E2=80=9Cbecause freedom=E2=80=9D= .

Unfortunately that is exactly the behaviour that was the source of the prob= lems with this thread.

I do not want to be on such a toxic list, even more so now that as a result= of this IETF Chair action reversal, those people are further emboldened in= their Abu=E2=80=99s I=E2=80=99ve behaviour.

I am now unsubscribing from the list.=C2=A0

Paul
--00000000000076e66d05acd92588-- From nobody Fri Aug 14 12:20:18 2020 Return-Path: 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 A03CB3A11F0 for ; Fri, 14 Aug 2020 12:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 u6Uo9k9kSZbP for ; Fri, 14 Aug 2020 12:20:15 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03B013A11AC for ; Fri, 14 Aug 2020 12:20:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 7AEC3B88F688 for ; Fri, 14 Aug 2020 14:20:10 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80_9X5cN_SLd for ; Fri, 14 Aug 2020 14:20:03 -0500 (CDT) Received: from [172.16.1.6] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 38A95B88F619 for ; Fri, 14 Aug 2020 14:20:03 -0500 (CDT) From: "Pete Resnick" To: gendispatch@ietf.org Date: Fri, 14 Aug 2020 14:19:37 -0500 X-Mailer: MailMate (1.13.1r5704) Message-ID: <8E0873AA-AC5F-4B2D-9E19-979D56E8398E@episteme.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: [Gendispatch] GenDispatch Virtual Interim doodle poll X-BeenThere: gendispatch@ietf.org 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: Fri, 14 Aug 2020 19:20:17 -0000 I got a chance to chat with Francesca, and so I've set up a doodle poll: https://doodle.com/poll/xzkzwxahhz9nph2f I've chosen a bunch of times that are good or bad to varying degrees for Europe, the Americas, east Asia, and the South Pacific. I'll see if we can get agreement on two meetings that everyone can at least say, "If Needed" to one of them. Please fill it out ASAP so we can get these meetings scheduled. Thanks, pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Sun Aug 16 18:06:48 2020 Return-Path: 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 3EF0E3A12C1 for ; Sun, 16 Aug 2020 18:06:46 -0700 (PDT) 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=mnot.net header.b=IRR1FI8z; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XlOHyeJq 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 88OiQ61RsfYK for ; Sun, 16 Aug 2020 18:06:44 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C4A3A12C3 for ; Sun, 16 Aug 2020 18:06:44 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id BA3F448F for ; Sun, 16 Aug 2020 21:06:43 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 16 Aug 2020 21:06:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:mime-version:subject:message-id:references:to :date; s=fm3; bh=sC67a2rAbWwvqsc7OxHibuPJSEaBP6eg/TGJtVBSe/c=; b= IRR1FI8zSf6oH7RmT0U4QOiTgiOd5FotvlRRhM//tCtgrG+QbNC4wIVBDgCH8oXc h4zwZMmHxPqYSs5s87ZPQFauRa1xmxxU5/e5Q3FV8V/pWteJVrgtDbOWcPDt4zWy OAdRbvu3OLdFvWx+S/89wBj6yI//gPzgeDq/S613oEdMy0p/4G410YXZ5X/z1BnX QFBPUoD4RCXAgl0UmqkgRWZ9OqvUb6AEUszCdLQE9TpJGCWfmUDDvskDW86W5fe+ 9a3H2Z4e29ONLlSKY2EGyR+JzviYpY+wZ2eQSUOV94ocPRDX6NOVaH/C+tSCgv08 PDWYJIldRek56gsNHWucbg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:references:subject:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=sC67a2rAbWwvqsc7O xHibuPJSEaBP6eg/TGJtVBSe/c=; b=XlOHyeJqcJeKjjS1S78u1i3Dau87wJHPl gH/CQB22wdPbDv3FRX3od9q9V6YUJTahWjxB5+38fcdG3ymjBE5cK1+aJliWRFVS VpAcfCetj+zFy52WYm1laujlfoJUuL2ZkpWYZZ4Tpuer4INb1sOysLrF0HBiZmyJ 6Sn6kSj+b/ljoUvN4BUwCFlXy4F8HGnmEDRNXtCW5vMHKiiNPvBLJZ/z8+Er39No xGugOv+LgfRkcwyvIPfGbkeFJwmrnPSLAIAlqhA/LqqV0vfZYtaKLZrLiNMPDo2D krc7bPgZnxUsY6ZFhw4btvcN1gqJ/RdAzR8apwTzdY7cbQ6qcvKkg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtvddggeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtggguffkfhfvfffosegrtdhmre hhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehmnhho thdrnhgvtheqnecuggftrfgrthhtvghrnhepieeiffeutdetkeejjeetueefleejkeejte fgfeettdetvdfgvdeitdefjeffgfeunecuffhomhgrihhnpehivghtfhdrohhrghdpmhhn ohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: 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 9EDE13280059 for ; Sun, 16 Aug 2020 21:06:41 -0400 (EDT) From: Mark Nottingham Content-Type: multipart/alternative; boundary="Apple-Mail=_DD39C31B-C77E-4797-972E-09C26AD82282" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: References: <159762600075.21012.17906525106566603063@ietfa.amsl.com> To: gendispatch@ietf.org Date: Mon, 17 Aug 2020 11:06:38 +1000 X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Gendispatch] Fwd: New Version Notification for draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Mon, 17 Aug 2020 01:06:46 -0000 --Apple-Mail=_DD39C31B-C77E-4797-972E-09C26AD82282 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I'd like this draft to be dispatched. Cheers, > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nottingham-discussion-recharter-00.txt > Date: 17 August 2020 at 11:00:00 am AEST > To: "Mark Nottingham" >=20 >=20 > A new version of I-D, draft-nottingham-discussion-recharter-00.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Name: draft-nottingham-discussion-recharter > Revision: 00 > Title: Rechartering the IETF Discussion List > Document date: 2020-08-17 > Group: Individual Submission > Pages: 7 > URL: = https://www.ietf.org/internet-drafts/draft-nottingham-discussion-recharter= -00.txt > Status: = https://datatracker.ietf.org/doc/draft-nottingham-discussion-recharter/ > Htmlized: = https://tools.ietf.org/html/draft-nottingham-discussion-recharter-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-nottingham-discussion-recharte= r >=20 >=20 > Abstract: > This document updates RFC3005, the charter of the IETF discussion > list. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 -- Mark Nottingham https://www.mnot.net/ --Apple-Mail=_DD39C31B-C77E-4797-972E-09C26AD82282 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

I'd = like this draft to be dispatched.

Cheers,


Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-nottingham-discussion-recharter-00.txt
Date: = 17 August 2020 at 11:00:00 am = AEST
To: = "Mark Nottingham" <mnot@mnot.net>

A new version of I-D, = draft-nottingham-discussion-recharter-00.txt
has been = successfully submitted by Mark Nottingham and posted to the
IETF repository.

Name: = draft-nottingham-discussion-recharter
Revision: 00
Title:= = Rechartering the IETF Discussion List
Document = date: = 2020-08-17
Group: Individual Submission
Pages:= = 7
URL: =            https://www.ietf.org/internet-drafts/draft-nottingham-discussio= n-recharter-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-nottingham-discussion-re= charter/
Htmlized: =       https://tools.ietf.org/html/draft-nottingham-discussion-rechart= er-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-nottingham-discussi= on-recharter


Abstract:
  This document updates RFC3005, the charter of = the IETF discussion
  list.




Please note that = it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



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

= --Apple-Mail=_DD39C31B-C77E-4797-972E-09C26AD82282-- From nobody Sun Aug 16 18:30:18 2020 Return-Path: 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 751543A12D1 for ; Sun, 16 Aug 2020 18:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, 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 (1024-bit key) header.d=joelhalpern.com 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 7Y0oU_iORGvN for ; Sun, 16 Aug 2020 18:30:15 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 302A73A12D0 for ; Sun, 16 Aug 2020 18:30:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4BVGgp75LMz1nvCg; Sun, 16 Aug 2020 18:30:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1597627814; bh=gfLnhPt0WkiiN9LD+GvzJsjOmHTOKUrcMS87m3IMb6s=; h=Subject:To:References:From:Date:In-Reply-To:From; b=RBkeKDUmlcJtqEZuQHz+8wOiCPw3XvysmndV6HjaISmUdI+nKU0/DOJhVy4adguNO rV8vP8alsw8lseiAyVhZK3xMteIqk5iYDVYE9Fu0InYzdC5VxnxrvPmP7BARrmKLHv bKaSTk4A8eZnzzDVVzgCHOe3cZta2EFlnVvj1uPI= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4BVGgp3QlKz1nsYV; Sun, 16 Aug 2020 18:30:14 -0700 (PDT) To: Mark Nottingham , gendispatch@ietf.org References: <159762600075.21012.17906525106566603063@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <636fdf51-feed-5db0-8392-d234fa01b605@joelhalpern.com> Date: Sun, 16 Aug 2020 21:30:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Gendispatch] Fwd: New Version Notification for draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Mon, 17 Aug 2020 01:30:16 -0000 Do you intend this to be coupled with a re-chartering of gendispatch to enable it to be a venue for disucssing the substance of proposals? The current charter prohibits that. As such, it seems to me that without such a change, if the proposal you are bringing forward in this document is adopted, there would be no place in the IETF to discuss the substance of proposals of procedural / administrative / or widely cross area interest. Conversely, if such a change were made to the charter, and if your proposal were adopted, why do you think that the gendispatch list would not promptly suffer from the same problems that the IEtF list has, in most of the dimensions you cite? Yours, Joel On 8/16/2020 9:06 PM, Mark Nottingham wrote: > Hi, > > I'd like this draft to be dispatched. > > Cheers, > > >> Begin forwarded message: >> >> *From: *internet-drafts@ietf.org >> *Subject: **New Version Notification for >> draft-nottingham-discussion-recharter-00.txt* >> *Date: *17 August 2020 at 11:00:00 am AEST >> *To: *"Mark Nottingham" > >> >> >> A new version of I-D, draft-nottingham-discussion-recharter-00.txt >> has been successfully submitted by Mark Nottingham and posted to the >> IETF repository. >> >> Name:draft-nottingham-discussion-recharter >> Revision:00 >> Title:Rechartering the IETF Discussion List >> Document date:2020-08-17 >> Group:Individual Submission >> Pages:7 >> URL: >> https://www.ietf.org/internet-drafts/draft-nottingham-discussion-recharter-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-nottingham-discussion-recharter/ >> Htmlized: >> https://tools.ietf.org/html/draft-nottingham-discussion-recharter-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-nottingham-discussion-recharter >> >> >> Abstract: >> This document updates RFC3005, the charter of the IETF discussion >> list. >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org >> . >> >> The IETF Secretariat >> >> > > -- > Mark Nottingham https://www.mnot.net/ > > From nobody Sun Aug 16 19:20:26 2020 Return-Path: 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 80F8A3A12EC for ; Sun, 16 Aug 2020 19:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: 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_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=mnot.net header.b=gwzwiCZE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Fmq4hBZd 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 6suA4vX_0zjb for ; Sun, 16 Aug 2020 19:20:22 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A181A3A12EB for ; Sun, 16 Aug 2020 19:20:22 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 95BDAAC4; Sun, 16 Aug 2020 22:20:21 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 16 Aug 2020 22:20:21 -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=fm3; bh=G TboLwQkYnCpyWGMvIsdbmjgtUMNHAAwZdDwT+ikqFg=; b=gwzwiCZEGpi4lDLpJ SUJffs2YxWXK+fvHo0krFYGakX4dLunERINas6aMwNBy7PwbWKUVCdSBJnH2v1+M GeRnvf64xVQdQViwo+jqcICV3ElI8Kb0pW1CICN3JBuMuPVGQmltMa9vq4bQw1cO 4HyCS7sw9bJzkHH1oAwEUwHpH3IrKi8RTBU0/JmFddVM5kXxYd2gjqRxvmD4NPKw iHEFo4mPyUbDRf/c7sTfLJJpIgwlyIbGRpCULh2GKYgPEP/i1cywTnO0tWnxRSgn Zze/P+eO/vJaRhBMhjGJwAXEVmCtEMPF4vPKYNpRj0fE88/a7GZ0lkcmPMEB6JnL IjMYg== 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=fm3; bh=GTboLwQkYnCpyWGMvIsdbmjgtUMNHAAwZdDwT+ikq Fg=; b=Fmq4hBZdRt6Cg8aegXVTFx3GoISLdwhesWm1MinPN1+33nvVPkCeqoR3a dhV2HCzpD57h9rVmdMKDnHfmnE3XDmfHAjbwLVPbDttukHvijFYP8kbpZ9ULvbD8 RPHMfGd+N/aD9pbZgsrJpX65ST7UfMJS8EZnqNMEmZPzGSafBpgbggl+Y4xqhHhC 8fu9QKPf3lW2I1uzkUrRn0ROZKjfrV5xP5yo9exoX4az+FiiznJgkpeCyIPtgz0l ezQwGF4epuOygGT6mcJAuwExgS7Dp6XFmdHrLHchHBVgri91M7W+++TVZVLQo6Zk A5DP4ENPDGsYxQwRhMZOKUKh6FxRg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtvddgiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehm nhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeduvdeljeegtefhveekhfdtveekle evkeefgeeludeihfdugedvieeuffdttdfhnecuffhomhgrihhnpehivghtfhdrohhrghdp mhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhn vght X-ME-Proxy: 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 1AA48328005D; Sun, 16 Aug 2020 22:20:18 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <636fdf51-feed-5db0-8392-d234fa01b605@joelhalpern.com> Date: Mon, 17 Aug 2020 12:20:16 +1000 Cc: gendispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4C6E3D97-885D-4FB5-8F1A-1E036FBD036E@mnot.net> References: <159762600075.21012.17906525106566603063@ietfa.amsl.com> <636fdf51-feed-5db0-8392-d234fa01b605@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Gendispatch] New Version Notification for draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Mon, 17 Aug 2020 02:20:25 -0000 Hi Joel, > On 17 Aug 2020, at 11:30 am, Joel M. Halpern = wrote: >=20 > Do you intend this to be coupled with a re-chartering of gendispatch = to enable it to be a venue for disucssing the substance of proposals? = The current charter prohibits that. As such, it seems to me that = without such a change, if the proposal you are bringing forward in this = document is adopted, there would be no place in the IETF to discuss the = substance of proposals of procedural / administrative / or widely cross = area interest. Good question, but a minor nit. The GENDISPATCH charter doesn't prohibit = discussion of proposals; indeed, it explicitly allows '[e]nsuring there = has been adequate mailing list discussion reflecting sufficient = interest.' However, the charter does imply that GENDISPATCH will not publish any = documents, so discussion after a proposal has been DISPATCHed might well = be considered out of scope. If that's what you mean by 'discussing the = substance of proposals', I agree that a change would be necessary -- if = we wanted to use GENDISPATCH to publish documents. That might or might not be necessary; creating new mailing lists for = documents (with an attached Working Group, or not if AD-sponsored) is an = effective way to keep the volume and tone of conversation manageable. It = might become desirable to re-charter GENDISPATCH to allow it to publish = uncontentious, 'small' documents, but that's a decision that doesn't = have to be coupled to this proposal. Additionally, I'd reinforce that this proposal does _not_ close the IETF = discussion list; people could continue to use it for discussing whatever = they currently do. However, if they want those discussions to have = impact on IETF policy or technology, they'll need to eventually take = them elsewhere. > Conversely, if such a change were made to the charter, and if your = proposal were adopted, why do you think that the gendispatch list would = not promptly suffer from the same problems that the IEtF list has, in = most of the dimensions you cite? I think that it would be different, for a few reasons. First, IETF Working Groups (and WG-like structures) can and do impose = stricter controls over participation than on the IETF discussion list = (RFC2418, RFC3934). As compared with RFC3005, these rules give the Chair = the authority to 'refuse to grant the floor to any individual who is = unprepared or otherwise covering inappropriate material, or who, in the = opinion of the Chair, is disrupting the WG process.' They're also more tightly focused; part of the problem with the IETF = discussion list is that it's extremely wide-ranging, so that = participants have to weather a number of different discussions to stay = up-to-date. GENDISPATCH can fork work streams off to new groups or new = mailing lists. WG mailing lists are also biased towards closure; they're chartered to = do something, and so the charter can be used to measure whether = discussion is on-topic. Beyond that, though, I'd suggest there's a considerable difference in = how people think about the discussion list as compared to WG lists. = Having a normal Chair making a call about the disposition of a proposal = -- along with the normal appeal processes -- gives participants more = effective guidance about where to focus discussion, and makes it easier = to be productive. For whatever reason, people seem more willing to work = with a Chair than they are to have discipline meted out by the SAA and = IESG. For example, the WG-like rfced-future program is discussing one of the = more contentious topics in recent memory, and yet the participants have = managed to remain civil, and early results show that it's reasonably = productive (despite the limitations imposed by the pandemic). Now, = consider if the IETF discussion list remained the venue for that topic.=20= That's not to say that a discussion of the matter at hand on GENDISPATCH = or anther WG mailing list wouldn't be contentious, or that some people = wouldn't be able to express their opinions (a chair that was too = heavy-handed would be quickly appealed). But, it would have a better = chance of concluding instead of endlessly circling, and properly = managed, it would remove the need for people who are interested in other = matters to be exposed to such a high-volume and often acrimonious list. Cheers, > Yours, > Joel >=20 > On 8/16/2020 9:06 PM, Mark Nottingham wrote: >> Hi, >> I'd like this draft to be dispatched. >> Cheers, >>> Begin forwarded message: >>>=20 >>> *From: *internet-drafts@ietf.org >>> *Subject: **New Version Notification for = draft-nottingham-discussion-recharter-00.txt* >>> *Date: *17 August 2020 at 11:00:00 am AEST >>> *To: *"Mark Nottingham" > >>>=20 >>>=20 >>> A new version of I-D, draft-nottingham-discussion-recharter-00.txt >>> has been successfully submitted by Mark Nottingham and posted to the >>> IETF repository. >>>=20 >>> Name:draft-nottingham-discussion-recharter >>> Revision:00 >>> Title:Rechartering the IETF Discussion List >>> Document date:2020-08-17 >>> Group:Individual Submission >>> Pages:7 >>> URL: = https://www.ietf.org/internet-drafts/draft-nottingham-discussion-recharter= -00.txt >>> Status: = https://datatracker.ietf.org/doc/draft-nottingham-discussion-recharter/ >>> Htmlized: = https://tools.ietf.org/html/draft-nottingham-discussion-recharter-00 >>> Htmlized: = https://datatracker.ietf.org/doc/html/draft-nottingham-discussion-recharte= r >>>=20 >>>=20 >>> Abstract: >>> This document updates RFC3005, the charter of the IETF discussion >>> list. >>>=20 >>>=20 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org = . >>>=20 >>> The IETF Secretariat >>>=20 >>>=20 >> -- >> Mark Nottingham https://www.mnot.net/ -- Mark Nottingham https://www.mnot.net/ From nobody Sun Aug 16 19:27:35 2020 Return-Path: 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 CFF3A3A12F3 for ; Sun, 16 Aug 2020 19:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, NICE_REPLY_A=-0.949, 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 (1024-bit key) header.d=joelhalpern.com 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 NAciKD9Wuhdc for ; Sun, 16 Aug 2020 19:27:32 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67DC73A12F2 for ; Sun, 16 Aug 2020 19:27:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4BVHxw1P16z1nvmk; Sun, 16 Aug 2020 19:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1597631252; bh=uUhztLsrnua2a61qz8HwCA1KYFsdGwYKro5uG3rie2c=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=heLEdVMk/yrXGeFoirEmeMyCtpojOTOlKdTizTsMNZMIZAKpkk6UoLOX/Xvj+EUan yxOCnQkzon+Sni3tkYe96PwMnPbi9tHpAMrE4+ey3mIUNxr+paKdiL/tpz+uD5/zVM GB/N66ShKAEgiD5Fj1tqV+wU867Z01eXVVmP2GdI= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4BVHxv4v65z1nvZZ; Sun, 16 Aug 2020 19:27:31 -0700 (PDT) To: Mark Nottingham Cc: gendispatch@ietf.org References: <159762600075.21012.17906525106566603063@ietfa.amsl.com> <636fdf51-feed-5db0-8392-d234fa01b605@joelhalpern.com> <4C6E3D97-885D-4FB5-8F1A-1E036FBD036E@mnot.net> From: "Joel M. Halpern" Message-ID: <420798bc-5edb-2b88-5de1-3cd2b615fdaf@joelhalpern.com> Date: Sun, 16 Aug 2020 22:27:30 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <4C6E3D97-885D-4FB5-8F1A-1E036FBD036E@mnot.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Gendispatch] New Version Notification for draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Mon, 17 Aug 2020 02:27:34 -0000 Thank you for the clarifications. The idea seems to me worth thinking about. Yours, Joel On 8/16/2020 10:20 PM, Mark Nottingham wrote: > Hi Joel, > >> On 17 Aug 2020, at 11:30 am, Joel M. Halpern wrote: >> >> Do you intend this to be coupled with a re-chartering of gendispatch to enable it to be a venue for disucssing the substance of proposals? The current charter prohibits that. As such, it seems to me that without such a change, if the proposal you are bringing forward in this document is adopted, there would be no place in the IETF to discuss the substance of proposals of procedural / administrative / or widely cross area interest. > > Good question, but a minor nit. The GENDISPATCH charter doesn't prohibit discussion of proposals; indeed, it explicitly allows '[e]nsuring there has been adequate mailing list discussion reflecting sufficient interest.' > > However, the charter does imply that GENDISPATCH will not publish any documents, so discussion after a proposal has been DISPATCHed might well be considered out of scope. If that's what you mean by 'discussing the substance of proposals', I agree that a change would be necessary -- if we wanted to use GENDISPATCH to publish documents. > > That might or might not be necessary; creating new mailing lists for documents (with an attached Working Group, or not if AD-sponsored) is an effective way to keep the volume and tone of conversation manageable. It might become desirable to re-charter GENDISPATCH to allow it to publish uncontentious, 'small' documents, but that's a decision that doesn't have to be coupled to this proposal. > > Additionally, I'd reinforce that this proposal does _not_ close the IETF discussion list; people could continue to use it for discussing whatever they currently do. However, if they want those discussions to have impact on IETF policy or technology, they'll need to eventually take them elsewhere. > >> Conversely, if such a change were made to the charter, and if your proposal were adopted, why do you think that the gendispatch list would not promptly suffer from the same problems that the IEtF list has, in most of the dimensions you cite? > > I think that it would be different, for a few reasons. > > First, IETF Working Groups (and WG-like structures) can and do impose stricter controls over participation than on the IETF discussion list (RFC2418, RFC3934). As compared with RFC3005, these rules give the Chair the authority to 'refuse to grant the floor to any individual who is unprepared or otherwise covering inappropriate material, or who, in the opinion of the Chair, is disrupting the WG process.' > > They're also more tightly focused; part of the problem with the IETF discussion list is that it's extremely wide-ranging, so that participants have to weather a number of different discussions to stay up-to-date. GENDISPATCH can fork work streams off to new groups or new mailing lists. > > WG mailing lists are also biased towards closure; they're chartered to do something, and so the charter can be used to measure whether discussion is on-topic. > > Beyond that, though, I'd suggest there's a considerable difference in how people think about the discussion list as compared to WG lists. Having a normal Chair making a call about the disposition of a proposal -- along with the normal appeal processes -- gives participants more effective guidance about where to focus discussion, and makes it easier to be productive. For whatever reason, people seem more willing to work with a Chair than they are to have discipline meted out by the SAA and IESG. > > For example, the WG-like rfced-future program is discussing one of the more contentious topics in recent memory, and yet the participants have managed to remain civil, and early results show that it's reasonably productive (despite the limitations imposed by the pandemic). Now, consider if the IETF discussion list remained the venue for that topic. > > That's not to say that a discussion of the matter at hand on GENDISPATCH or anther WG mailing list wouldn't be contentious, or that some people wouldn't be able to express their opinions (a chair that was too heavy-handed would be quickly appealed). But, it would have a better chance of concluding instead of endlessly circling, and properly managed, it would remove the need for people who are interested in other matters to be exposed to such a high-volume and often acrimonious list. > > Cheers, > > >> Yours, >> Joel >> >> On 8/16/2020 9:06 PM, Mark Nottingham wrote: >>> Hi, >>> I'd like this draft to be dispatched. >>> Cheers, >>>> Begin forwarded message: >>>> >>>> *From: *internet-drafts@ietf.org >>>> *Subject: **New Version Notification for draft-nottingham-discussion-recharter-00.txt* >>>> *Date: *17 August 2020 at 11:00:00 am AEST >>>> *To: *"Mark Nottingham" > >>>> >>>> >>>> A new version of I-D, draft-nottingham-discussion-recharter-00.txt >>>> has been successfully submitted by Mark Nottingham and posted to the >>>> IETF repository. >>>> >>>> Name:draft-nottingham-discussion-recharter >>>> Revision:00 >>>> Title:Rechartering the IETF Discussion List >>>> Document date:2020-08-17 >>>> Group:Individual Submission >>>> Pages:7 >>>> URL: https://www.ietf.org/internet-drafts/draft-nottingham-discussion-recharter-00.txt >>>> Status: https://datatracker.ietf.org/doc/draft-nottingham-discussion-recharter/ >>>> Htmlized: https://tools.ietf.org/html/draft-nottingham-discussion-recharter-00 >>>> Htmlized: https://datatracker.ietf.org/doc/html/draft-nottingham-discussion-recharter >>>> >>>> >>>> Abstract: >>>> This document updates RFC3005, the charter of the IETF discussion >>>> list. >>>> >>>> >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of submission >>>> until the htmlized version and diff are available at tools.ietf.org . >>>> >>>> The IETF Secretariat >>>> >>>> >>> -- >>> Mark Nottingham https://www.mnot.net/ > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Sun Aug 16 19:36:28 2020 Return-Path: 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 327613A12F6 for ; Sun, 16 Aug 2020 19:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 fTnx_Vb8rkvq for ; Sun, 16 Aug 2020 19:36:24 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C6E3A12F7 for ; Sun, 16 Aug 2020 19:36:24 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id B9F35A57 for ; Sun, 16 Aug 2020 22:36:23 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 16 Aug 2020 22:36:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=pZxG7ke4rQepq29mLfZhBxkQw+mIsmpDHdW2ZMWUm zI=; b=pJgPEhHTTbHgVVax5aEFJpOYgKFsoW7dNn2XbCQF/PnF6gnId8TOqncEZ p92xvO4Ah4NuUeEBBGjCuj0bq7jyMd/LLhzCp6I4CH/fJtlGuZnb38zF5Ozktyh1 paxh+RNgZ+q8Oh47aopHvyNhXuz1LzW0LUY3tE0lkoCPFyqbCU1nYDoL2X63zu0f i5PxBivXJ2eCrTedvR0X0yksxy7uCAyIvJmN3nm5q/qXYg9krdhxNTHqlNwaraOR iPmM66PI0kTLR2cnHacI1x2ldF8c73t8XFWssxFZP7CKaBXM3LvC5EbhL2w0bwCg yqrMDCwh/iseIQoPzsLKZaeQdV8xQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtvddgieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeehnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeehudfhleduge euteevvefhueejjeefffefteettddvleefgfekieekheejffdvffenucfkphepuddtkedr vddvuddrudektddrudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id C6680328005A for ; Sun, 16 Aug 2020 22:36:22 -0400 (EDT) To: gendispatch@ietf.org References: <159762600075.21012.17906525106566603063@ietfa.amsl.com> From: Keith Moore Message-ID: <372b6a7c-1700-9333-e7bd-349f79a6146d@network-heretics.com> Date: Sun, 16 Aug 2020 22:36:21 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] Fwd: New Version Notification for draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Mon, 17 Aug 2020 02:36:26 -0000 Some comments on initial reading of this draft: 1. I agree that the IETF list is not representative, though I disagree that it's unproductive. IMO the recent discussion labeled as "not helpful" was actually quite illustrative of the problems with the proposal, though some people may have been reluctant to consider feedback that didn't fit their agendas. I think section 1.2 of the I-D illustrates other problems, e.g. that the SAAs should not take direction from the IETF chair and should instead be subject to independent oversight. It may also illustrate that the SAAs need a wider range of tools to apply (like automatic redirecting to another public list, see below) than warning and censorship. 2. We make decisions by (rough) consensus rather than by voting. As such the IETF list doesn't have to be representative of the community to be useful; if leadership is made aware of coherent objections via the ietf@ietf.org list, such objections are indicators of a lack of community consensus and need to be taken seriously. Just as the ietf@ietf.org list is not representative, neither is any other IETF mailing lists even representative of its community or subject area. The Last Calls and ietf@ietf.org list serve as a useful (though imperfect) backstop against narrowly-focused WGs causing problems for interests outside of those WGs' subject areas. 3. IMO, IETF lists in general could use some re-organizing and more thought given to how to make discussions over email effective, given present day email user agents, webmail, mobile devices, etc. IMO the ietf@ietf.org list should serve as a "center" of sorts for IETF - to discuss topics of general interest to the IETF and the Internet itself. It should still serve as a place to bring up concerns about how the IETF is run and to offer suggestions for improvement. But the volume needs to be kept low enough to not discourage participants who just want to keep a finger on the pulse of IETF, so to speak. So whenever a discussion reaches a certain amount of traffic and/or starts to become heated, it might make sense to redirect some discussions to a pre-existing (yet also public) side list that probably not everyone would want to subscribe to. The way I imagine this might happen is that the SAAs could arrange for any message with a particular subject pattern to be automatically redirected to the side list, and a (single) announcement sent to ietf@ietf.org saying "this discussion has been redirected to the xxx@ietf.org list" along with pointers in that message to the subscribe instructions and the archive for that list. Any messages with that subject already posted to the ietf@ietf.org list should also be forwarded to the side list so they can all be archived in one place. The side list wouldn't create much of a new barrier to participation because people would only need to subscribe to it once. Another slightly different way to look at this would be to have two lists (say ietf-full and ietf-lite) with the -lite traffic being a moderated subset of the -full traffic. Again, it might be useful if the readers of -lite were informed about new discussions on the -full list, say in a weekly message with a link to each discussion, so that readers of the -lite list could be aware of such discussions. I also think that a separate list (say draft-...-NN-lastcall@ietf.org) should be created for each Last Call, and all traffic that's a reply to the Last Call announcement should automatically be redirected there, again so that all of the traffic ends up in the same place and only the people interested in that particular discussion need subscribe (or read it via an archive). Clearly we can't have a single list for all ietf-related topics, so I'm interested in seeing if there's a better way to fragment discussion that doesn't present as many barriers to cross-group and cross-area participation as mailman subscriptions do. I am opposed to most of the specific proposals in draft-nottingham-discussion-recharter but agree that it's worth considering some changes to how some IETF lists are operated. I hope we can have a productive discussion about what kinds of changes might be helpful, without prematurely getting too polarized about what those changes should be. (As Joel Halpern pointed out, as currently chartered, gendispatch is not the place to have that discussion.) Keith From nobody Mon Aug 17 00:27:03 2020 Return-Path: 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 957923A0598 for ; Mon, 17 Aug 2020 00:27:02 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=gmail.com 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 REUGv3KcKZq3 for ; Mon, 17 Aug 2020 00:27:01 -0700 (PDT) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58C9A3A03FC for ; Mon, 17 Aug 2020 00:27:01 -0700 (PDT) Received: by mail-io1-xd2e.google.com with SMTP id g13so2382593ioo.9 for ; Mon, 17 Aug 2020 00:27:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ioiKka3pScHztZMfW7q1bLohCiaqkGEaB0EoSPiMnFg=; b=X6+V5+o/i7Pkn2lBDbwVQSkbvkPfjk9Aq8q+RkIFFWDZWqptenP4H2HccbrNqNa8zW AGd2r0sNuK8/wMTzVsvCcF7LuWuMHRTUruBSzIS0TF+E5yAlXQKshM98w4aqUrkzcvx/ jUMaShovob5N0UOABQec1Zr5REYfxdxh7/fBQdj1m+ZYIYMnUpatPGJNdyrN23F0vHsI 3CnCgsHMHpA2Mq2Y4i6olvpx+xwhqD3BPOY4mLLDLMifn8qH5Zeb3Ws7VUURnyMru8EL vBXUsAMcftu9jPb0l7vIpBRcGjY2gZl6TnxQqDDqxpRozoVmQ3jFt+PePfJ7wpVPaa0w JEGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ioiKka3pScHztZMfW7q1bLohCiaqkGEaB0EoSPiMnFg=; b=E+VTytMrDCFszw8umpHYuGiqQliOjFWGFaOpnZg+ObR5bgvpzm/olVCbMnAqiVY915 9pTBsnXLXZosqzyQSQdERuMPOekxiAzc0KedgCO7p3gORVfVxEEPBgoc/ELffHxCZCXS 59yj0R9+NwFvwQp2uRiHUk5khCbimNIFM5d8vMbz7V2sy5bGpu1TM45I/Fi1ym++nVVO jP99UoUeaSjF1R6GiYVZGVzJh+52QQNO4NPd2ektCjYOcx+wSIgEZND78Ec3JPf7cZFY luqdnmcdVs7xbteEGFzVC/Ge67kCYN8xme1a77BOzBiItlT3C5R4BQQemh6+3nIf2Xod M6VQ== X-Gm-Message-State: AOAM530o/7yVAYC8i78HVxD53wd0NSV6/4EIeAqK/bUnpHiBmLImyJ2v LHCi6oWUpernWkipjaV/fmvGf7nVjGSaf1mF2KulosqwU94vjQ== X-Google-Smtp-Source: ABdhPJxQHnccVYaJEvnmlB5DoDta8740g6oEDrO8GY6bzcK0HwLFMmPG+LLuPvmYnnU2JLgfUZjRz5dGs12P4GiTw7A= X-Received: by 2002:a02:84c1:: with SMTP id f59mr13540211jai.106.1597649220250; Mon, 17 Aug 2020 00:27:00 -0700 (PDT) MIME-Version: 1.0 From: Rob Sayre Date: Mon, 17 Aug 2020 00:26:49 -0700 Message-ID: To: gendispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000003fb47405ad0db2e6" Archived-At: Subject: Re: [Gendispatch] Fwd: New Version Notification for draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Mon, 17 Aug 2020 07:27:03 -0000 --0000000000003fb47405ad0db2e6 Content-Type: text/plain; charset="UTF-8" Hi, I just joined this list. So, apologies if the reply headers aren't quite right. I strongly support this draft: https://www.ietf.org/internet-drafts/draft-nottingham-discussion-recharter-00.txt thanks, Rob --0000000000003fb47405ad0db2e6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I just joined this list. So, apolog= ies if the reply headers aren't quite right.

I= strongly support this draft:


thanks,
Rob

=


--0000000000003fb47405ad0db2e6-- From nobody Mon Aug 17 22:49:53 2020 Return-Path: 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 EF9FC3A1790 for ; Mon, 17 Aug 2020 22:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: 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_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=mnot.net header.b=igAFJ3Yu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PdWBJPZG 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 QnwiBIMVo6xn for ; Mon, 17 Aug 2020 22:49:49 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A903A178F for ; Mon, 17 Aug 2020 22:49:49 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id CA152A24; Tue, 18 Aug 2020 01:49:48 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 18 Aug 2020 01:49:48 -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=fm3; bh=r /HLtYQkAWi1SBwvhVQ4xs/7fN6lcMz8ExXzsjXDvU8=; b=igAFJ3YuXN5HTroeN rQjl34DujPiLK9fMohEeJbhdmYwfGLiqpO/q5LMx/oYTh7yETJWmL0bPafkU2dxO s0Y1oI3fuYUXHjfE4Wj3NoYPvi3vkZln5xriDMXA/YOQ+BuysenWutkc74Yn+qtx c86wjmxQC2ClipomsBJbAjLWjc5XZop0UieiwulXvo/XuA83EfH8lqa8jHaYR5NS 0OZKJwEVANCjIkdqGGkhKQgt/JuuSP31Zc9UYyTvvrkCv75EtdaiFW1yxo9o8oIs 95PoN8jczWcKTsH2LuwXRvDZvAxfkoNCzsejj++bF0aB9qCmx+YssJZGIOsOpug8 YMMpg== 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=fm3; bh=r/HLtYQkAWi1SBwvhVQ4xs/7fN6lcMz8ExXzsjXDv U8=; b=PdWBJPZG8uwDlzUJIxzUe4fipVSbWux8k/naHp1xGCbNWc/N2U1UxUAFl zlTF8/3GOhhSZyWlY4inb7Gk9m3XxgkbjdLUbjeHhAluzmyga1Nzn1gzSchlWGYm E0IgSeKIrEImeWeIuQvKJRKPUeoxhjljDcH7t03q7M11mfCMGnkvvzDZFsyTJQfU A7n0g8z/S4J9EFI9G79bnarhQ2R+zTwmyENBmYs4FWnX7iukfVGF2qeETTw0T/B6 a0ZFhIwyhWz/i9mNwurXrO0+1WwmvvDM1QWMOJ4RwC2S+VAIXbJ+EjrBUl+nun5P IOkVxPHGJ8O07zxu6BPkHx/afpsFA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddthedgleejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeevffffhfduteevvefhueffieegtdeutdehffeltefffedttdeggeejheeiueet teenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvd ehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvght X-ME-Proxy: 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 12F1A3280063; Tue, 18 Aug 2020 01:49:45 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: Date: Tue, 18 Aug 2020 15:49:43 +1000 Cc: gendispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 05:49:52 -0000 Hi Brian, As promised, discussion on the GENDISPATCH list. Thanks for the = comments, they're good food for thought. Some responses below. > On 18 Aug 2020, at 12:46 pm, Brian E Carpenter = wrote: >=20 >> This document updates RFC3005, the charter of the IETF discussion >> list. >=20 > Then its intended status needs to be BCP. Thanks, will update. >> Comparing its membership to a sample of other IETF mailing lists, = we >> find that there are typically many members that are not taking part >> on the IETF discussion list: >=20 > People specialise. The intersection count given (628) is therefore not = a > useful statistic. The intersection with the union of all WG mailing = lists > would be useful. But for now, we simply do not know how many = subscribers > to at least one WG are missing from the ietf list, and we do not know = how > many subscribers to ietf are subscribed to no WG list. Those numbers = could > be discovered, of course. >=20 > If I had to guess, I'd use ietf-announce as a proxy for active = participation, > and that would suggest that at (most) 1799/3037 =3D 59% of active = participants > were on the ietf list at the end of July. That imperfect measurement = is a > good deal higher than the estimates in the draft. That's not comparing apples and apples, though -- we need to get the = portion of those subscribed to both lists to those subscribed to = ietf-announce@.=20 Jay said that 1,087 were subscribed to ietf@ but not ietf-announce@; = given that ietf-announce@ has 3,038 and ietf@ has 1,751, so I think the = right figure is 21.8%. BTW, since I wrote the draft, the subscriber lists for a couple more = mailing lists have become available: - art: 26.8% - last-call: 93.9% Last-call is an interesting case, in that it shows we can spool up a new = list and migrate specific kinds of discussion over successfully (in = particular, without the acrimonious aspect of much ietf@ discussion). > As I said earlier, there is evidence that only a small fraction (10%?) = of > the ietf list is interested enough in policy/process/admin to = subscribe to > lists on those topics. So using my imperfect measurement above, we = find that > at a generous estimate, 6% of IETF participants care about = policy/process/admin. I don't disagree. I included the data more to motivate the second and = third statements in the recommendations, quoted below. >> 2. The IESG should not consider the IETF discussion list as an >> appropriate venue for notifying IETF participants of its = actions >> or items under consideration.=20 >=20 > That's not new. The formal channel has been ietf-announce (which is = not a > discussion list) for 20+ years. True, the IESG sometimes puts the ietf = list > in Cc:, but since ietf-announce is not a discussion list, that's a = natural > thing to do. Thus: >=20 >> More suitable channels include the >> IETF Announcements list and the GENDISPATCH Working Group, >> depending on the notification. >=20 > is standard operating procedure. It is, but reminding people of this might be worthwhile; while the = Secretariat, the IETF Chair and the IAB Chair are good at this, there = are occasions where others (e.g., individual ADs, NomCom chairs, etc.) = use the ietf@ list as an announcement channel. >> 3. The IESG should not consider the IETF discussion list as >> representative of the broader IETF community. >=20 > Then where can the IESG go for that? (Of course, when something = reaches > a formal Last Call, we know the answer, but that is the very last = stage > in discussing a topic). It doesn't say that the IESG can't consider discussion on the IETF list = -- just that it cannot consider that discussion as solely representative = (because it can be skewed by a few loud voices). Again, I don't think = this is too far from the current operating procedure; most ADs I talk to = are very aware of the dynamics of the IETF list.=20 I'm happy to try to write this down more clearly. >> 4. IETF participants who wish to make proposals about or discuss = the >> IETF's direction, policy, meetings and procedures should do so = in >> GENDISPATCH or other Working Group, if one more specific to = that >> topic should exist. >=20 > Here's where it gets tricky. That is indeed what should happen as a > proposal crystallizes. But is the draft really saying that the plenary > discussion list shouldn't be used for the early rounds of discussion = of > an IETF-wide topic? That such topics should be discussed *from the = start > to finish* by the self-selected 6% or fewer of participants who are = process > wonks? That the rest of the IETF will only hear about it when a Last = Call > comes out? >=20 > That sounds like mushroom management to me. People can and will discuss whatever they like on the ietf@ list -- as I = said earlier on gendispatch@, this proposal does not include closing it. However, when they want their proposals to move forward, they'll need to = go elsewhere. Again, not a big change -- just writing down what we = already do. >> 5. IETF participants who wish to make proposals about or discuss >> technical issues should do so in the most appropriate Working >> Group or Area mailing list to the topic >=20 > That's mainly what people do. Just occasionally somebody (usually not > a regular participant) sends a technical query to the ietf list, and > usually gets politely redirected. I think it's great when that = happens. Indeed. >> 7. There should be no explicit or implicit requirement for IETF >> leadership or any other person to be subscribed to the IETF >> discussion list. >=20 > I absolutely utterly violently disagree. I must confess that the day > I stepped down from the IAB, I dropped the ietf list, but after a year > or so I realised that just wasn't viable unless I only wanted to work > in my own tiny corner of the protocol stack, and I rejoined. (There is > a handy delete button in my MUA, which I have always used very freely = on > ietf@ietf.org threads.) Looking at the content of the list over the last year or so (subtracting = messages also sent to ietf-announce@ and the now-moved last call = discussions), I see very little technical content, and even less that = really spans multiple areas. So the ietf@ list doesn't promote cross-participation technically; = that's a fiction. If someone wants to broadly participate across the = IETF, they subscribe to multiple lists and participate in multiple = areas, using the area WGs and/or dispatch groups to get a sense of = what's going on elsewhere. > It isn't acceptable to me that IAB or IESG members would *not* keep an > eye on the list. Why? I really want to understand what value you think is realised by = them doing so. > In summary, I think the proposed changes would change the list from > being mainly useful but sometimes toxic, to being mainly toxic and = rarely > useful. I don't agree with the characterisation of the list in its current form = as 'mainly useful but sometimes toxic' -- 'mainly toxic and rarely = useful' is much more apt. I'd be interested to hear what others think, = though. I do agree that these changes aren't likely to make it more useful. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Aug 17 23:01:42 2020 Return-Path: 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 B6A5C3A1792 for ; Mon, 17 Aug 2020 23:01:40 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=gmail.com 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 IdmFKhNUx6OS for ; Mon, 17 Aug 2020 23:01:39 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F38B03A1460 for ; Mon, 17 Aug 2020 23:01:38 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id k4so16626879ilr.12 for ; Mon, 17 Aug 2020 23:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YQneiEuX1ad/HMMsZ8XrxuTMrhmtdmNIqEXjYwQzA9w=; b=A2UOHO1L5mqAYk2rDKief+XHYkdwBJOQF6duyIaipWyRY18Fa44mJA3KjFS1grysf1 PH8rmLlXQp/qJsTuwIX6LxWrQP18J+OYuj6Z2QMFszAjubduwbpDgtsLRrNa+Dvyhaf0 V8yWp0Kf09GNV50dBUcCDGigsgBJHwe1YV3oFLqrsZt6C+bKsfC4ehGqOSjvcDWJF6cz ggT56qg+EcrcadzWur2eQFrEhizsS6tztkdrrOE8o+22Jo4Ofl/qx2R8od4bQ9iVuQ1K UfqTC7yZWt+2gZsRGkvpsG4xP5nmo5Jmfnwh9KpV8pVLGoPK9gx99ftyaxpWy5jEWvLh 4yug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YQneiEuX1ad/HMMsZ8XrxuTMrhmtdmNIqEXjYwQzA9w=; b=pSrWGA9+temwoWsaTG15z/K+qc5wl62lQmzqN9jT77WO63A1tzVj1fg62MzuLasSTg YBGtPxA46GnGY3H3yNxuWMRvKFvMgrFne1cRUlUJzbdX3xyDSWGSLulqJhuYNVvrYSco KsK8T/F9f3+TBPFuYICo/yY7iCvuP3VkOiOqx1glogglguVyrjwDEo+F8cL4znwSeEkN sTFr6aNhH/ChjDEI4Lj/GD6/+/oEre6hdig8AUphLK0wIdyHV57YlNe8VkZF8szjT+Fy x2CZk9ZCLkLCEdhHghwjKWeOtFz0IMBcKT4Cl1Jdw6RiFtsLRs0igYrPf0mqg1zsuVEt Pjxg== X-Gm-Message-State: AOAM530oFQbvngEFX4RfeeEPN6AgDd15SzfzHf1bSru/ZsrpV7GSHTRU 9J8qKJ3pGOph0oNaAVsDLWeEsKSq3+Kr5T+7+E0= X-Google-Smtp-Source: ABdhPJz0i7X+8j50akcOoXcjERj9IMwHitnVwNccM2//h6rF6isEfm0eJXh6Q8tWC5Ox8CzIDK8ub3Q/dQcRBbGSHig= X-Received: by 2002:a92:c904:: with SMTP id t4mr16769634ilp.257.1597730498089; Mon, 17 Aug 2020 23:01:38 -0700 (PDT) MIME-Version: 1.0 References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> In-Reply-To: <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> From: Rob Sayre Date: Mon, 17 Aug 2020 23:01:27 -0700 Message-ID: To: Mark Nottingham Cc: Brian E Carpenter , gendispatch@ietf.org Content-Type: multipart/alternative; boundary="000000000000c91a6b05ad209e04" Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 06:01:41 -0000 --000000000000c91a6b05ad209e04 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 17, 2020 at 10:49 PM Mark Nottingham wrote: > > In summary, I think the proposed changes would change the list from > > being mainly useful but sometimes toxic, to being mainly toxic and rarely > > useful. > > I don't agree with the characterisation of the list in its current form as > 'mainly useful but sometimes toxic' -- 'mainly toxic and rarely useful' is > much more apt. I'd be interested to hear what others think, though. > Agree with Mark. I don't think the ietf@ list is useful most of the time, but it is often toxic. This draft is the correct remedy, as it removes the audience some email senders seem to think they are entitled to. thanks, Rob --000000000000c91a6b05ad209e04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Aug 17, 2020 at 10:49 PM Mark Not= tingham <mnot@mnot.net> wrote:
> In summary, I think the proposed changes would change the list from > being mainly useful but sometimes toxic, to being mainly toxic and rar= ely
> useful.

I don't agree with the characterisation of the list in its current form= as 'mainly useful but sometimes toxic' -- 'mainly toxic and ra= rely useful' is much more apt. I'd be interested to hear what other= s think, though.

Agree with Mark. I don= 't think the ietf@ list is useful most of the time, but it is often tox= ic.

This draft is the correct remedy, as it remove= s the audience some email senders seem to think they are entitled to.
=

thanks,
Rob
--000000000000c91a6b05ad209e04-- From nobody Tue Aug 18 03:25:00 2020 Return-Path: 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 AFAE53A0802 for ; Tue, 18 Aug 2020 03:24:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.948 X-Spam-Level: X-Spam-Status: No, score=-2.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 wGw3uyN5C1dQ for ; Tue, 18 Aug 2020 03:24:57 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6B393A07F9 for ; Tue, 18 Aug 2020 03:24:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 70BA0BE4C; Tue, 18 Aug 2020 11:24:54 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZI4WX-Ok6pts; Tue, 18 Aug 2020 11:24:53 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C95A2BE39; Tue, 18 Aug 2020 11:24:52 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1597746292; bh=2R2Smi6hNfbW09a0POA/zsDRJEQo+EZGhWOO21e/cck=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=hv5hx/TjoQ0AxDjvv77RlWshHGn7d/XYB92/i2mxOjuVADhJBtwPBuLjKo3lZeVTW Fql5bMVMTDcUIEvgCrvx65TYg2wp/7JCypiNui24PY23nRcbJLn5lfKx7b8z8tB+31 l13He52TWT0yTEVT65QOoGKHcrfZE35NzdI0peME= To: Mark Nottingham , Brian E Carpenter Cc: gendispatch@ietf.org References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <22a13e31-5b71-8e8d-d2e4-cc769d5cc91b@cs.tcd.ie> Date: Tue, 18 Aug 2020 11:24:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sxnIM4xcQmAagdYtKfaBopooq3EEv1Ziy" Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 10:24:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sxnIM4xcQmAagdYtKfaBopooq3EEv1Ziy Content-Type: multipart/mixed; boundary="z5XneuIFXCpsWGbFLUH7XrRo9y04UUub5"; protected-headers="v1" From: Stephen Farrell To: Mark Nottingham , Brian E Carpenter Cc: gendispatch@ietf.org Message-ID: <22a13e31-5b71-8e8d-d2e4-cc769d5cc91b@cs.tcd.ie> Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> In-Reply-To: <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> --z5XneuIFXCpsWGbFLUH7XrRo9y04UUub5 Content-Type: multipart/mixed; boundary="------------56BF391448407F5D3A4D91DB" Content-Language: en-US This is a multi-part message in MIME format. --------------56BF391448407F5D3A4D91DB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 18/08/2020 06:49, Mark Nottingham wrote: > I don't agree with the characterisation of the list in its current > form as 'mainly useful but sometimes toxic' -- 'mainly toxic and > rarely useful' is much more apt. I'd be interested to hear what > others think, though. I think that the level of subjectivity involved makes me wonder if it's worthwhile trying to figure that out. FWIW, I'd characterise ietf@ietf as "mostly boring, sometimes annoying, rarely useful but overall still needed for the few IETF things that need really broad list discussion." I doubt gendispatch is a good substitute for things that do need such broad discussion so I'm not sure if this draft can end up useful. S. --------------56BF391448407F5D3A4D91DB Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------56BF391448407F5D3A4D91DB-- --z5XneuIFXCpsWGbFLUH7XrRo9y04UUub5-- --sxnIM4xcQmAagdYtKfaBopooq3EEv1Ziy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl87rHMACgkQWrL68XsX K+p+tBAAzllzQ6tZoNsko7tEACGEcEIUAeFkQ/vTkRjfHspLonrD6d0dQL7dJ7Ed Sm7iEvp3FZb4arrLFbDL3NXx/X6R8pmgVjCiuH28p71DcxpDdSgTzChm5q9xZSuR heX30h/HtP56aDHjlnAdyWlBU2wJhEgNVGazxc8+JwB4UANrZELWhonl7i9PDdu9 ZFEFLszb6Aeh/+qAV2N5rwpfuR+5PvYbjuIlDlfVmJ5W9GxzT9pGZu0z/id24SCR Un7+ZVAf5E2kPqA2b1xYyGFGfHS+dh4Abm1RZebcJt06/g8SW2wdR4ESVFu12790 k/50FeNnr/LHAM1wlV9Z+6lIMakTf7WtpGxdp9ugCtIsH0/qEC0PWVBncMMZ8WKs UuXcIIyNqYnA2VYBdty6eT4NSEIrzArn/XA9R0gN8ggmcI+95U1NU7FZGrEOafSX xNLsv41mRojWYWG2N9NQL9H0no3+pwdXoYwtxG8jUBC2w9XgcCD4FAQYnOmugK5U Jfok8FZecdYIj3AWicsD0XvdeiVACBgi6KgsdPMHBrzUGbDb2czJYrKU08OonyYh 1avI1TvpbaDWD9XqgyGE0gxJLD85w9YkumJrfm4RXym0yzAsrn3qzDLTKe1eY4Gu ZB4n4RyfPdeAq86u77L1BJzDr0NCYneh46dcixf4fKcZXz3XZXE= =UNYS -----END PGP SIGNATURE----- --sxnIM4xcQmAagdYtKfaBopooq3EEv1Ziy-- From nobody Tue Aug 18 03:54:09 2020 Return-Path: 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 185973A0766 for ; Tue, 18 Aug 2020 03:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Oexmnbdx0U7p for ; Tue, 18 Aug 2020 03:54:05 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 404023A0745 for ; Tue, 18 Aug 2020 03:54:05 -0700 (PDT) Received: from p200300dee72156000cd8e88136bbc164.dip0.t-ipconnect.de ([2003:de:e721:5600:cd8:e881:36bb:c164]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1k7zFi-0003Ef-3m; Tue, 18 Aug 2020 12:54:02 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mirja Kuehlewind In-Reply-To: <22a13e31-5b71-8e8d-d2e4-cc769d5cc91b@cs.tcd.ie> Date: Tue, 18 Aug 2020 12:54:00 +0200 Cc: Stephen Farrell , Brian E Carpenter Content-Transfer-Encoding: quoted-printable Message-Id: References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <22a13e31-5b71-8e8d-d2e4-cc769d5cc91b@cs.tcd.ie> To: Mark Nottingham , gendispatch@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1597748045;6bcd944c; X-HE-SMSGID: 1k7zFi-0003Ef-3m Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 10:54:07 -0000 In terms of the usefulness ratio I's also say it=E2=80=99s low compared = to the total traffic volume and time investment (as a German I really = focus on efficient here :-) ). However, there is some useful feedback on = the list that we want to contain somehow. I=E2=80=99m really mostly = worried about the point that the feedback there is not representative. = The recent example is that we only got good replies to the meeting = survey when we also asked the chairs to announce it on their wg mailing = lists. We usually don=E2=80=99t do that because we don=E2=80=99t want to = spam those lists but in this case we really thought it also important = for the groups itself that the IESG and LLC get input from a large = community on how to hold online meetings. The ietf-announce and ietf = list were not able to generate that needed feedback. So I think what is = most important is to have a good way to reach a large portion of the = (active) community without requiring a large time investment from the = group of people that other are not subscribed to ietf@ or overly = interesting in most of the processing questions.=20 Mirja > On 18. Aug 2020, at 12:24, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > On 18/08/2020 06:49, Mark Nottingham wrote: >> I don't agree with the characterisation of the list in its current >> form as 'mainly useful but sometimes toxic' -- 'mainly toxic and >> rarely useful' is much more apt. I'd be interested to hear what >> others think, though. > I think that the level of subjectivity involved makes > me wonder if it's worthwhile trying to figure that out. >=20 > FWIW, I'd characterise ietf@ietf as "mostly boring, > sometimes annoying, rarely useful but overall still > needed for the few IETF things that need really broad > list discussion." >=20 > I doubt gendispatch is a good substitute for things > that do need such broad discussion so I'm not sure > if this draft can end up useful. >=20 > S. > <0x5AB2FAF17B172BEA.asc>--=20 > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch From nobody Tue Aug 18 04:34:58 2020 Return-Path: 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 D2DC63A08EC for ; Tue, 18 Aug 2020 04:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=akamai.com 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 Tfbt9jNJLOhj for ; Tue, 18 Aug 2020 04:34:55 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38C9D3A08EB for ; Tue, 18 Aug 2020 04:34:55 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07IBWhj3025161; Tue, 18 Aug 2020 12:34:54 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=GY+Vu/h8tfE4Z2LS7AXD/fQ77B9h95PBcEBbfXNPbiw=; b=QATRSiV4gBrIkji9wUBNKQVd+4EpN31k5cILT4/j0+D0/cs1XGC8N+SMRtbRsarPqR8l mrOSM5iC8qLWM8ea0PoFVojo7il/eVc6mVCh2w3pL1O2hcLMXKMDj+Z7hj/rO1pN4S2T 3nWl4nrBFkNvjbGd59R+7bSBiupuhwV4i9i3M7t5WreiA2TgvqOBD/nbV4cZeV3c6nxP WsmXDa6cRQ6wrmnWF+y8yWr4HnSCqOh9+McOfyT3Lo9weejA+g4UuFdEKKtzAhoL/uVm vA7O7ROfpcLIUtpUCP6HYKGobXh9WsNQtiXlXNY/uldScA0+cf3ddTnTRSMCBTXH5lw5 GQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 3304m51thm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Aug 2020 12:34:54 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 07IBWKVu021101; Tue, 18 Aug 2020 07:34:53 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 32xb1xjbtf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 18 Aug 2020 07:34:53 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 18 Aug 2020 07:34:52 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1497.006; Tue, 18 Aug 2020 07:34:52 -0400 From: "Salz, Rich" To: Mark Nottingham CC: "gendispatch@ietf.org" Thread-Topic: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt Thread-Index: AQHWdQnnOx27rqM9kEa/cTAscvAiaKk9n7iAgAADR4CAABoZAA== Date: Tue, 18 Aug 2020 11:34:52 +0000 Message-ID: <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.116.150] Content-Type: multipart/alternative; boundary="_000_0BD00993D00748E3ABAE157CCF0CE2C3akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-18_07:2020-08-18, 2020-08-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 mlxscore=0 bulkscore=0 spamscore=0 mlxlogscore=918 adultscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008180081 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-18_07:2020-08-18, 2020-08-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 clxscore=1015 impostorscore=0 lowpriorityscore=0 spamscore=0 mlxscore=0 phishscore=0 suspectscore=0 mlxlogscore=869 adultscore=0 bulkscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008180083 Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 11:34:57 -0000 --_000_0BD00993D00748E3ABAE157CCF0CE2C3akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBkb24ndCBhZ3JlZSB3aXRoIHRoZSBjaGFyYWN0ZXJpc2F0aW9uIG9mIHRoZSBsaXN0IGluIGl0 cyBjdXJyZW50IGZvcm0gYXMgJ21haW5seSB1c2VmdWwgYnV0IHNvbWV0aW1lcyB0b3hpYycgLS0g J21haW5seSB0b3hpYyBhbmQgcmFyZWx5IHVzZWZ1bCcgaXMgbXVjaCBtb3JlIGFwdC4gSSdkIGJl IGludGVyZXN0ZWQgdG8gaGVhciB3aGF0IG90aGVycyB0aGluaywgdGhvdWdoLg0KDQpJIHRoaW5r IHRoZSBJRVRGIGxpc3QgaXMgcmFyZWx5IHRveGljLiBNYXliZSBzaW5jZSBJIGdyZXcgdXAgb24g VXNlbmV0IGFuZCB4bWwtZGV2IEkgaGF2ZSBhIGhpZ2hlciB0b2xlcmFuY2UsIGJ1dCBJIGNhbuKA mXQgcmVjYWxsIGEgdG94aWMgdGhyZWFkIG90aGVyIHRoYW4gdGhlIGxhbmd1YWdlIG9uZS4gQW5k IGV2ZW4gdGhlbiwgbXkgZmVlbGluZ3MgYXJlIG1vcmUgc2Vuc2l0aXplZCBiZWNhdXNlIEkgcGFy dGljaXBhdGUgcGVyaGFwcyAoYW5kIHdhcyBqdXN0IHJlY2VudGx5IOKAnGJ1cm5lZOKAnSBieSB0 aGUgc2FtZSB0b3BpYyBvdmVyIGluIGFuIG9wZW4gc291cmNlIHByb2plY3QpLiBTbyBJ4oCZbSBj dXJpb3VzIHdoYXQgb3RoZXIgdG9waWMgdGhyZWFkcyBvdGhlcnMgY29uc2lkZXIgdG94aWMuDQoN Ckl0IGlzIG5vaXN5LCByZXBldGl0aXZlLCBhbmQgc29tZXRpbWVzIG5vdCB1c2VmdWwuIFNvIGFy ZSBodW1hbnMuIEp1c3QgYmVjYXVzZSBzb21ldGhpbmfigJlzIG5vdCBhbHdheXMgZ29vZCBkb2Vz buKAmXQgbWVhbiBpdOKAmXMgYmFkIG9yIGJyb2tlbiBhbmQgbmVlZHMgdG8gYmUgZml4ZWQuIE9w ZW5uZXNzIGlzIHdvcnRoIGl0LCBhbmQgaXQgY29tZXMgd2l0aCBjb3N0cyB3ZSBzaG91bGQgYmUg d2lsbGluZyB0byBwYXkuDQoNCkkgZGlzbGlrZSB0aGlzIGRyYWZ0IGFuZCBwcmVmZXIgaXQgZ2V0 cyBhYmFuZG9uZWQuDQoNCiAgICAgICAgICAgICAgICAvciQNCg0K --_000_0BD00993D00748E3ABAE157CCF0CE2C3akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <1447CC968D827C4BA763DA70E88FCB84@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgYWdyZWUgd2l0aCB0aGUg Y2hhcmFjdGVyaXNhdGlvbiBvZiB0aGUgbGlzdCBpbiBpdHMgY3VycmVudCBmb3JtIGFzICdtYWlu bHkgdXNlZnVsIGJ1dCBzb21ldGltZXMgdG94aWMnIC0tICdtYWlubHkgdG94aWMgYW5kIHJhcmVs eSB1c2VmdWwnIGlzIG11Y2ggbW9yZSBhcHQuIEknZCBiZSBpbnRlcmVzdGVkIHRvIGhlYXIgd2hh dCBvdGhlcnMgdGhpbmssIHRob3VnaC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlIElFVEYgbGlzdCBpcyByYXJl bHkgdG94aWMuIE1heWJlIHNpbmNlIEkgZ3JldyB1cCBvbiBVc2VuZXQgYW5kIHhtbC1kZXYgSSBo YXZlIGEgaGlnaGVyIHRvbGVyYW5jZSwgYnV0IEkgY2Fu4oCZdCByZWNhbGwgYSB0b3hpYyB0aHJl YWQgb3RoZXIgdGhhbiB0aGUgbGFuZ3VhZ2Ugb25lLiBBbmQgZXZlbiB0aGVuLCBteSBmZWVsaW5n cyBhcmUgbW9yZSBzZW5zaXRpemVkIGJlY2F1c2UgSSBwYXJ0aWNpcGF0ZQ0KIHBlcmhhcHMgKGFu ZCB3YXMganVzdCByZWNlbnRseSDigJxidXJuZWTigJ0gYnkgdGhlIHNhbWUgdG9waWMgb3ZlciBp biBhbiBvcGVuIHNvdXJjZSBwcm9qZWN0KS4gU28gSeKAmW0gY3VyaW91cyB3aGF0IG90aGVyIHRv cGljIHRocmVhZHMgb3RoZXJzIGNvbnNpZGVyIHRveGljLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JdCBpcyBub2lzeSwgcmVwZXRpdGl2ZSwgYW5kIHNvbWV0aW1lcyBub3QgdXNlZnVsLiBTbyBh cmUgaHVtYW5zLiBKdXN0IGJlY2F1c2Ugc29tZXRoaW5n4oCZcyBub3QgYWx3YXlzIGdvb2QgZG9l c27igJl0IG1lYW4gaXTigJlzIGJhZCBvciBicm9rZW4gYW5kIG5lZWRzIHRvIGJlIGZpeGVkLiBP cGVubmVzcyBpcyB3b3J0aCBpdCwgYW5kIGl0IGNvbWVzIHdpdGggY29zdHMgd2Ugc2hvdWxkIGJl IHdpbGxpbmcgdG8gcGF5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRpc2xpa2UgdGhpcyBk cmFmdCBhbmQgcHJlZmVyIGl0IGdldHMgYWJhbmRvbmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgL3IkPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0BD00993D00748E3ABAE157CCF0CE2C3akamaicom_-- From nobody Tue Aug 18 07:25:23 2020 Return-Path: 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 ABABC3A0B55 for ; Tue, 18 Aug 2020 07:25:21 -0700 (PDT) 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=HAb++clW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=q4V8Qlwe 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 awMEENt59hVx for ; Tue, 18 Aug 2020 07:25:20 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15AE43A0B50 for ; Tue, 18 Aug 2020 07:25:20 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 45178BDB for ; Tue, 18 Aug 2020 10:25:19 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 18 Aug 2020 10:25:19 -0400 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:subject:content-type; s=fm3; bh=gfpAd4p cGQZ8FcoPvqXwhqStFN0/ENYFK6rrjEdoRlQ=; b=HAb++clWRTaGsQYOX+RM5V5 66AQTuMQYqO/5q90iVO7/A+3PGO7WGVvVBeH3nPOBwYkF/+mwo/RK3Lne45bTMtS +OfC/HT/yiLvoHamyfx4kpZF9HyDIz/gXeHbvvKMSkZ1JABI4pRrRiJyC1wFLTpg z8plPK6I3m+PQdMG9AJx9o4zGDAFDZbnSPqf0eHao/gUFgLMR2W7JQhFCUj7yhuD mVrP3B24V0iSqVes7qv78AFz8u19vEi9MAPA0aUuS9pp1hExdA4SQjueYZoVEZ49 drWGKB7U7MSpxsNOx3v9nwYOs3fSW8u1jopXGPYmR4N8LLgq58EXJfsDPbmMVig= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=fm3; bh=gfpAd4 pcGQZ8FcoPvqXwhqStFN0/ENYFK6rrjEdoRlQ=; b=q4V8QlwebGeNv2gYJbXZds FTEuZp2mQiS7aUd7Jath3v3cOb9IevyCtrquKACFejayQZqJsD8AtDTJZEGVwukF xE9Fr1cxWdu4wQC50vDorByDsDEJpyz66d8n9Rz82YhSqfZt9TG2VHCFXVtFCIR0 +C5dffBG+1IDzcNlDFBIfhZzwrM/fUQlkh8q+rvb4a/eCEXSdYSXW2hI+FJt2aL+ LPKWUoHu2javAfpWzwAht5VFtw0iPJgY2E9NbyUSxemV8pY3Dz2bexbPbzKqEAUO 4Oo0murXOyB50pqam7CxWSG5QxNpk5SAqT+Y6Wc6nVOFw4ulbvKDIOYht4bojVwQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtiedgieeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpefhheeuheelhf ehgfelledthfffjeevgfevueehgfeiudfgkeegudevvdelhfdvtdenucffohhmrghinhep thhhvgdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AEAB418014A; Tue, 18 Aug 2020 10:25:18 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-191-gef79d59-fm-20200818.001-gef79d590 Mime-Version: 1.0 Message-Id: <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> In-Reply-To: <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> Date: Wed, 19 Aug 2020 00:24:57 +1000 From: "Bron Gondwana" To: gendispatch@ietf.org Content-Type: multipart/alternative; boundary=6d0cfc699ba24eb790835ce9fdcda5f6 Archived-At: Subject: Re: [Gendispatch] =?utf-8?q?I-D_Action=3A_draft-nottingham-discussio?= =?utf-8?q?n-recharter-00=2Etxt?= X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 14:25:22 -0000 --6d0cfc699ba24eb790835ce9fdcda5f6 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 18, 2020, at 21:34, Salz, Rich wrote: >> I don't agree with the characterisation of the list in its current fo= rm as 'mainly useful but sometimes toxic' -- 'mainly toxic and rarely us= eful' is much more apt. I'd be interested to hear what others think, tho= ugh. > =20 > I think the IETF list is rarely toxic. Maybe since I grew up on Usenet= and xml-dev I have a higher tolerance, but I can=E2=80=99t recall a tox= ic thread other than the language one. And even then, my feelings are mo= re sensitized because I participate perhaps (and was just recently =E2=80= =9Cburned=E2=80=9D by the same topic over in an open source project). So= I=E2=80=99m curious what other topic threads others consider toxic. > =20 I agree that it's not often toxic. Off the top of my head other recent = cases that got somewhat obnoxious are: * the nomcom validation process (also: nomcom eligibility for ietf107 go= t a bit off the rails) * meetecho reviews * criteria for deciding if IETF108 should be virtual * criteria for deciding if IETF107 should go ahead * anything about requiring IETF services to support ipv6 * anything that Jay has done, ever * spring-wg drama * the .org sale looking back to 2019: * IETF SMTP server was configured to block IP address HELO * RFCv3 format reviews * OMG Heather quit - GRAB THE PITCHFORKS WHO WAS AT FAULT WE MUST KNOW!!= ! * probably others The problem is, at the core of each of these is a complex problem that t= he IETF has to grapple with (except "all services must use ipv6", those = people are tilting at windmills), but conversations devolve into mud-sli= nging and tribes settling back into their familiar trenches quite easily= . I'm in two minds about Mark's proposal: On the one hand, plenty of people don't see things on that list because = of volume or disinterest. On the other, the answer to "why wasn't I consulted" can be "it was on t= he ietf@ietf list, that's how you find out". Or if it wasn't said on th= e list, that's when the complainer has reasonable grounds to be upset ab= out being uninformed. If we splinter to lots of places, I'm not convinced that the problems go= away. They are hard problems, and they won't be solved by a subset of = people with similar opinions as to the correct path forward working off = to one side, and then coming back with a pre-prepared solution and decla= ring the work to be finished. If anything, that will just lead to the l= ast-call list picking up all the problems that this list has, but at the= end when the only way to solve them is more extreme than hashing issues= out up-front (as painful as that is). I'm can imagine last-call would = become filled with "STRONG NO, THIS WORK IS WRONG AND SHOULDN'T HAVE BEE= N DONE. I OBJECT" rather than the current small tweaks on documents whe= re the main consensus work has already been done. As a moderator of last-call, I'm not keen on that as a path forward! Regards, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --6d0cfc699ba24eb790835ce9fdcda5f6 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 18, 2020, at 21:34, Salz, Rich wrote:
=

I don't agree with t= he characterisation of the list in its current form as 'mainly useful bu= t sometimes toxic' -- 'mainly toxic and rarely useful' is much more apt.= I'd be interested to hear what others think, though.

 

I think the IETF list is rarely toxic. Maybe since I grew up= on Usenet and xml-dev I have a higher tolerance, but I can=E2=80=99t re= call a toxic thread other than the language one. And even then, my feeli= ngs are more sensitized because I participate perhaps (and was just recently =E2=80=9Cburned=E2=80=9D by the same top= ic over in an open source project). So I=E2=80=99m curious what other to= pic threads others consider toxic.

&nbs= p;


I agree that it's n= ot often toxic.  Off the top of my head other recent cases that got= somewhat obnoxious are:

=
* the nomcom validation process = (also: nomcom eligibility for ietf107 got a bit off the rails)
=
* meetecho reviews
* criteria for deciding if IETF108 should be vir= tual
* criteria for deciding = if IETF107 should go ahead
* = anything about requiring IETF services to support ipv6
* anything that Jay has done, ever
* spring-wg drama
* the .org sale

looking back to 2019= :

* IETF SMTP server was configured to block IP address H= ELO
* RFCv3 format reviews
* OMG Heather quit - GRAB THE P= ITCHFORKS WHO WAS AT FAULT WE MUST KNOW!!!
* probably others
<= br>
The problem is, at the core o= f each of these is a complex problem that the IETF has to grapple with (= except "all services must use ipv6", those people are tilting at windmil= ls), but conversations devolve into mud-slinging and tribes settling bac= k into their familiar trenches quite easily.

I'm in two m= inds about Mark's proposal:
<= br>
On the one hand, plenty of pe= ople don't see things on that list because of volume or disinterest.
=

On the other, the answer to "why wasn't I consulted" can be = "it was on the ietf@ietf list, that's how you find out".  Or if it = wasn't said on the list, that's when the complainer has reasonable groun= ds to be upset about being uninformed.

If we splinter to = lots of places, I'm not convinced that the problems go away.  They = are hard problems, and they won't be solved by a subset of people with s= imilar opinions as to the correct path forward working off to one side, = and then coming back with a pre-prepared solution and declaring the work= to be finished.  If anything, that will just lead to the last-call= list picking up all the problems that this list has, but at the end whe= n the only way to solve them is more extreme than hashing issues out up-= front (as painful as that is).  I'm can imagine last-call would bec= ome filled with "STRONG NO, THIS WORK IS WRONG AND SHOULDN'T HAVE BEEN D= ONE.  I OBJECT" rather than the current small tweaks on documents w= here the main consensus work has already been done.

As a mo= derator of last-call, I'm not keen on that as a path forward!
<= div style=3D"font-family:Arial;">
Regards,

Bron.


--
  Bron Gondwana, CEO, Fastmail Pty Lt= d
  brong@fastmailteam.com


--6d0cfc699ba24eb790835ce9fdcda5f6-- From nobody Tue Aug 18 07:27:42 2020 Return-Path: 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 29DE13A0B03 for ; Tue, 18 Aug 2020 07:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=akamai.com 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 UCewJWgzEJvi for ; Tue, 18 Aug 2020 07:27:39 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CFE3A0B29 for ; Tue, 18 Aug 2020 07:27:33 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07IER6Oh023909; Tue, 18 Aug 2020 15:27:29 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=04S81/pDR+gp49A1SzsRZ+etXtbyRaBRndM3TxAgZBE=; b=nfMXPbW9mZ2Oen8Fv0oIO0BNWgyTVYYdXIvIxMEKMTCiyLH18fbgFXoHpyVRGxek/hNl 6zEyRpdiGhjqra5aurxjjqj/iili2Ui5HYhY4pdC901jS1L4CEDRy/pTBtVFI1OwxLG1 7gzoz2fdHupqelLQ7g9RzAvHAI9YnXT0xxxX6IZ6tJB0Ttnd/fy4P6kC3v5ScchrivMl eOzsBguaq8LyauRJjGOed8UVNvzNbFt+269nhlE8ceChPP6CQaKFcmVpxSmppLVSSIbC +aA+hB1UYCsyYn1AVQY8i6/hwiH8oNg/19cgMWxS03A2L0/QIoT8cGXb9OvjbipJMeea fA== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 3304jk8e12-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Aug 2020 15:27:29 +0100 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 07IELBpM006224; Tue, 18 Aug 2020 10:27:28 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint6.akamai.com with ESMTP id 32xb1y6vtj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 18 Aug 2020 10:27:28 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 18 Aug 2020 10:27:27 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1497.006; Tue, 18 Aug 2020 10:27:27 -0400 From: "Salz, Rich" To: Bron Gondwana , "gendispatch@ietf.org" Thread-Topic: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt Thread-Index: AQHWdWtsO3mHgH/lf0GUZRaTXNsW8Kk97I6A Date: Tue, 18 Aug 2020 14:27:27 +0000 Message-ID: <0FB7A8DB-7C3D-4FBA-A195-06DC5462A843@akamai.com> References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> In-Reply-To: <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.116.150] Content-Type: multipart/alternative; boundary="_000_0FB7A8DB7C3D4FBAA19506DC5462A843akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-18_10:2020-08-18, 2020-08-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxscore=0 mlxlogscore=664 suspectscore=0 adultscore=0 malwarescore=0 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008180104 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-18_10:2020-08-18, 2020-08-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 lowpriorityscore=0 adultscore=0 impostorscore=0 mlxlogscore=615 spamscore=0 phishscore=0 mlxscore=0 suspectscore=0 priorityscore=1501 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008180105 Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 14:27:41 -0000 --_000_0FB7A8DB7C3D4FBAA19506DC5462A843akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSBhZ3JlZSB0aGF0IGl0J3Mgbm90IG9mdGVuIHRveGljLiAgT2ZmIHRoZSB0b3Agb2Yg bXkgaGVhZCBvdGhlciByZWNlbnQgY2FzZXMgdGhhdCBnb3Qgc29tZXdoYXQgb2Jub3hpb3VzIGFy ZToNCg0KV291bGQgeW91IGRlc2NyaWJlIGFueSBvZiB0aGUgY29udHJvdmVyc2lhbCBpdGVtcyBm cm9tIHlvdXIgbGlzdCBhcyB0b3hpYz8gIEkgbWlnaHQgcHV0IHRoZSBIZWF0aGVyIHRocmVhZCB0 aGVyZSwgaWYgcHJlc3NlZC4NCg== --_000_0FB7A8DB7C3D4FBAA19506DC5462A843akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <98BA1E8E1E9A2F4A97BE0C8FD06B0A69@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjExODU0ODE4MjY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjY2OTMwNzc4NiAtMjA5MTQ1MzQ0OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFuc2ktZm9udC13ZWlnaHQ6Ym9sZDt9DQpAbGlzdCBsMDps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8ZGl2Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlz YyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj5JIGFncmVlIHRoYXQgaXQncyBub3Qgb2Z0ZW4gdG94aWMu Jm5ic3A7IE9mZiB0aGUgdG9wIG9mIG15IGhlYWQgb3RoZXIgcmVjZW50IGNhc2VzIHRoYXQgZ290 IHNvbWV3aGF0IG9ibm94aW91cyBhcmU6PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldvdWxkIHlvdSBkZXNjcmliZSBhbnkgb2YgdGhlIGNv bnRyb3ZlcnNpYWwgaXRlbXMgZnJvbSB5b3VyIGxpc3QgYXMgdG94aWM/Jm5ic3A7IEkgbWlnaHQg cHV0IHRoZSBIZWF0aGVyIHRocmVhZCB0aGVyZSwgaWYgcHJlc3NlZC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0FB7A8DB7C3D4FBAA19506DC5462A843akamaicom_-- From nobody Tue Aug 18 07:30:24 2020 Return-Path: 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 E10443A0B3B for ; Tue, 18 Aug 2020 07:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 OM09b-0VyCUW for ; Tue, 18 Aug 2020 07:30:20 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2F83A0B34 for ; Tue, 18 Aug 2020 07:30:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 818BCB91512E for ; Tue, 18 Aug 2020 09:30:16 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BC4IAXea2lXO for ; Tue, 18 Aug 2020 09:30:15 -0500 (CDT) Received: from [172.16.1.10] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id AF246B915125 for ; Tue, 18 Aug 2020 09:30:15 -0500 (CDT) From: "Pete Resnick" To: gendispatch@ietf.org Date: Tue, 18 Aug 2020 09:30:15 -0500 X-Mailer: MailMate (1.13.1r5704) Message-ID: <7F182A25-424B-40FB-9414-91410A8524CF@episteme.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: [Gendispatch] Results of Doodle poll X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 14:30:22 -0000 Francesca and I looked at the results of the Doodle, and here are the proposed dates and times (in UTC) for two interim meetings we plan to hold: Tuesday, 1 September at 20:00-22:00 Monday, 7 September at 11:00-13:00 That seemed to us to get everyone able to attend at least one meeting, and enough people who can make both to carry over some context. Yes, we scheduled 2 hours per meeting; we don't have to use all of it. As the saying goes: Speak now or forever hold your peace. Francesca will be preparing a message with an agenda and a description of goals soon. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Tue Aug 18 07:42:42 2020 Return-Path: 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 2A3353A0B86 for ; Tue, 18 Aug 2020 07:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 yyKLc4ym8X0a for ; Tue, 18 Aug 2020 07:42:39 -0700 (PDT) Received: from mail-vk1-xa2f.google.com (mail-vk1-xa2f.google.com [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1D73A0B80 for ; Tue, 18 Aug 2020 07:42:39 -0700 (PDT) Received: by mail-vk1-xa2f.google.com with SMTP id r197so4353761vkf.13 for ; Tue, 18 Aug 2020 07:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MLtR8Gy4C/kH2XQ9OjOVW6SUyV9VR1GUMiNxI6hcY8U=; b=pG1bfLQKkFazCV97MxvP1vkUkfFMYHnyCbGCx64jRu5GWRB7twQdUUca7fCfxyomws p5K5+gTsvtS8+o33AGoTocs+3reVW8ZO+nf0pP0ybJN4pBQmnKCaFp7bhcXoAcPaFC9j c2MLcuCOf8jZiYgm9DgJvftmI8RiXgAHdDhI4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MLtR8Gy4C/kH2XQ9OjOVW6SUyV9VR1GUMiNxI6hcY8U=; b=lF765arDjly8jVMESkOdOCjUQAYkuvnFY4fH7qqllwwDjwA3RorhwJBbbcmIzgzBYD 0+PKtBP7Tf7AtqYS4w88S3fDilC13qnNXXDK8e3eaBTSF3GKsC8O0quNCkckXLHIEH/n g/pz009Q/vMv/4g+GSkOrDQQ9GtMI1lNyQW4GSDzQjUcbnUTmYS7iWvsfrpYpDDyRgQ3 XdPVjw58wpw8f+4fHAXnyTcJauqsVe5PQWEswkqW2OX7qzw+5/6hzgts+6Q2BZt3yWjc YeXCDe7m4jW/df+3hwA9GowfjHhyWStLuj4Npv5Swe8rkZVQRrf7nY6/se0ateqUiuHZ qewQ== X-Gm-Message-State: AOAM530SwBmmJuwMNB37I51i66Mc9ZMGkgroA0BnIyizT3S69n9z65pX 8McWlPl7Ex283yY2hkS0mGHAn0CEAOH0431nqJtJJFwykTw= X-Google-Smtp-Source: ABdhPJzAMg6KirucnrkOzUNpSB53LQ4m5i632PgBcWkSUbk8rojIGikoMXE8vnkPE0piSwLRJAnIcoRiJH6rFo6Spho= X-Received: by 2002:a1f:de81:: with SMTP id v123mr11030704vkg.92.1597761758312; Tue, 18 Aug 2020 07:42:38 -0700 (PDT) MIME-Version: 1.0 References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> In-Reply-To: <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> From: Kyle Rose Date: Tue, 18 Aug 2020 10:42:27 -0400 Message-ID: To: Bron Gondwana Cc: gendispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000000a52ad05ad27e680" Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 14:42:41 -0000 --0000000000000a52ad05ad27e680 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 18, 2020 at 10:25 AM Bron Gondwana wrote: > On Tue, Aug 18, 2020, at 21:34, Salz, Rich wrote: > > I don't agree with the characterisation of the list in its current form a= s > 'mainly useful but sometimes toxic' -- 'mainly toxic and rarely useful' i= s > much more apt. I'd be interested to hear what others think, though. > > > > I think the IETF list is rarely toxic. Maybe since I grew up on Usenet an= d > xml-dev I have a higher tolerance, but I can=E2=80=99t recall a toxic thr= ead other > than the language one. And even then, my feelings are more sensitized > because I participate perhaps (and was just recently =E2=80=9Cburned=E2= =80=9D by the same > topic over in an open source project). So I=E2=80=99m curious what other = topic > threads others consider toxic. > > > > > I agree that it's not often toxic. Off the top of my head other recent > cases that got somewhat obnoxious are: > Can we stop using the word "toxic" in our analysis of the problem? One person's toxic thread is another person's debate on a serious, material complaint. That sometimes the discussions devolve into name calling by some shouldn't be used as a justification for downplaying the seriousness of the underlying issues. The SAA's role should be to keep the discussion civil and to, in a progression, gently remind/warn/reprimand/punish those who violate decorum. They should never shut down a discussion entirely, nor should they target a participant or one whole side of a debate on a serious, material complaint. Furthermore, action should be taken only for things we can establish rough consensus are bad: I suspect this means personal and ad hominem attacks, insults, and language intended to denigrate, e.g., racial epithets and the like. Kyle --0000000000000a52ad05ad27e680 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 18, 2020 at 10:25 AM Bron Gondwana <brong@fastmailteam.com> wrote:
On Tue, Aug 18, 2020, at 21:34, Salz, Rich wrote:
=

I don't agree with the characterisation of the li= st in its current form as 'mainly useful but sometimes toxic' -- &#= 39;mainly toxic and rarely useful' is much more apt. I'd be interes= ted to hear what others think, though.

=C2=A0

I think the IETF list is rarely toxic. Maybe since I gr= ew up on Usenet and xml-dev I have a higher tolerance, but I can=E2=80=99t = recall a toxic thread other than the language one. And even then, my feelin= gs are more sensitized because I participate perhaps (and was just recently =E2=80=9Cburned=E2=80=9D by the same topic = over in an open source project). So I=E2=80=99m curious what other topic th= reads others consider toxic.

=C2=A0


I agree that it's not often toxic.=C2=A0 Off the top of= my head other recent cases that got somewhat obnoxious are:

Can we stop using the word "toxic" in our analysis = of the problem? One person's toxic thread is another person's debat= e on a serious, material complaint. That sometimes the discussions devolve = into name calling by some shouldn't be used as a justification for down= playing the seriousness of the underlying issues.

The SAA's role should be to keep the discussio= n civil and to, in a progression, gently remind/warn/reprimand/punish those= who violate decorum. They should never shut down a discussion entirely, n= or should they target a participant or one whole side of a debate on a seri= ous, material complaint. Furthermore, action should be taken only for thing= s we can establish rough consensus are bad: I suspect this means personal a= nd ad hominem attacks, insults, and language intended to denigrate, e.g., r= acial epithets and the like.

Kyle
--0000000000000a52ad05ad27e680-- From nobody Tue Aug 18 09:01:33 2020 Return-Path: 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 E569A3A0E02; Tue, 18 Aug 2020 09:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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=csperkins.org 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 0wV7z-cgE9-X; Tue, 18 Aug 2020 09:01:25 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25D2D3A0DF7; Tue, 18 Aug 2020 09:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=CN9aVjq1ezgGUcq6kwW0MtNULLRxA5a6uQGrwl1LQ/8=; b=yNwl+BFB1WVLmZooUmRP6jW5cM LK59rXJoaY3ooTIitfk5XXNE04fGThMy6gh58LVw6KQhtFmaO4rKxA0HSV2MCm0k3ta9n396Ix+mT OACKGKkOdE3yeIJzrpMOWdb2xM11T3wBKxu2+tcVoZCIGmiF5K3R1SPnqfpN6bQFttDx1eelgFd3R kdk/Ptiu5rCBZs0qO28odV050ZUIQufY/JzgumCxJkA3tTWUiyN1AniuPKNiHaKZvW5IzAhPbObJ9 XDlW/dO3YqlB6gbIlWS/MDetRIXwdXLfM3jeCUZqrh9qj1paZzgXnFWjt4SnTNmme/NlSf3f4DU/y 5503eiGA==; Received: from [81.187.2.149] (port=44990 helo=[192.168.0.80]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1k842q-0002Ej-CF; Tue, 18 Aug 2020 17:01:20 +0100 From: Colin Perkins Message-Id: <256AB2A2-3936-4D72-95D2-12FFBB893326@csperkins.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_45A5479E-522A-490F-BA9A-6938BB98BAFD" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Date: Tue, 18 Aug 2020 17:01:01 +0100 In-Reply-To: Cc: Brian E Carpenter , gendispatch@ietf.org To: Jay Daley References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.15) X-BlackCat-Spam-Score: 14 Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 16:01:32 -0000 --Apple-Mail=_45A5479E-522A-490F-BA9A-6938BB98BAFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 18 Aug 2020, at 04:10, Jay Daley wrote: >=20 > Brian >=20 >> On 18/08/2020, at 2:46 PM, Brian E Carpenter = > = wrote: >>=20 >>> This document updates RFC3005, the charter of the IETF discussion >>> list. >>=20 >> Then its intended status needs to be BCP. >>=20 >>> Comparing its membership to a sample of other IETF mailing lists, = we >>> find that there are typically many members that are not taking = part >>> on the IETF discussion list: >>=20 >> People specialise. The intersection count given (628) is therefore = not a >> useful statistic. The intersection with the union of all WG mailing = lists >> would be useful. But for now, we simply do not know how many = subscribers >> to at least one WG are missing from the ietf list, and we do not know = how >> many subscribers to ietf are subscribed to no WG list. Those numbers = could >> be discovered, of course. >=20 > I am in the process of determining data like this for a number of = reasons and so I can give you some interim results now. =20 >=20 > First the disclaimer: >=20 > * I=E2=80=99m relying on mailman storing email addresses consistently = and I have not completely checked that it does > * I am counting address with different +box notation as a single = subscriber > * Addresses that have been disabled by bounce processing are counted = the same as those that are not (one of the main reasons these are only = interim results) > * This data is from three weeks ago and will have changed since then >=20 > With that in mind, the interim results are: >=20 > 1. The membership of ietf@ was 1796 distinct subscribers=20 >=20 >=20 > 2. There were 55,894 distinct email addresses subscribed to mailing = lists that allow open subscription >=20 > 3. 123 subscribers to ietf@ did not subscribe to any other list If I=E2=80=99m wrangling the datatracker correctly: 1608 subscribers to ietf@ietf.org =E2=80=A6932 of whom subscribe to at least one list for an active = working group =E2=80=A6676 do not appear to be subscribed to any of the active working = groups 20264 subscribers to mailing lists for active working groups.=20 Colin >>=20 >> If I had to guess, I'd use ietf-announce as a proxy for active = participation, >> and that would suggest that at (most) 1799/3037 =3D 59% of active = participants >> were on the ietf list at the end of July. That imperfect measurement = is a >> good deal higher than the estimates in the draft. >=20 > 4. Three weeks ago the membership of ietf-announce was 3038 >=20 > 5. 800 were subscribed to ietf-announce@ and no other list >=20 > 6. 1087 were subscribed to ietf@ but not ietf-announce@ >=20 > Jay >=20 >>=20 >> As I said earlier, there is evidence that only a small fraction = (10%?) of >> the ietf list is interested enough in policy/process/admin to = subscribe to >> lists on those topics. So using my imperfect measurement above, we = find that >> at a generous estimate, 6% of IETF participants care about = policy/process/admin. >>=20 >>> 2. The IESG should not consider the IETF discussion list as an >>> appropriate venue for notifying IETF participants of its = actions >>> or items under consideration.=20 >>=20 >> That's not new. The formal channel has been ietf-announce (which is = not a >> discussion list) for 20+ years. True, the IESG sometimes puts the = ietf list >> in Cc:, but since ietf-announce is not a discussion list, that's a = natural >> thing to do. Thus: >>=20 >>> More suitable channels include the >>> IETF Announcements list and the GENDISPATCH Working Group, >>> depending on the notification. >>=20 >> is standard operating procedure. >>=20 >>>=20 >>> 3. The IESG should not consider the IETF discussion list as >>> representative of the broader IETF community. >>=20 >> Then where can the IESG go for that? (Of course, when something = reaches >> a formal Last Call, we know the answer, but that is the very last = stage >> in discussing a topic). >>=20 >>> 4. IETF participants who wish to make proposals about or discuss = the >>> IETF's direction, policy, meetings and procedures should do so = in >>> GENDISPATCH or other Working Group, if one more specific to = that >>> topic should exist. >>=20 >> Here's where it gets tricky. That is indeed what should happen as a >> proposal crystallizes. But is the draft really saying that the = plenary >> discussion list shouldn't be used for the early rounds of discussion = of >> an IETF-wide topic? That such topics should be discussed *from the = start >> to finish* by the self-selected 6% or fewer of participants who are = process >> wonks? That the rest of the IETF will only hear about it when a Last = Call >> comes out? >>=20 >> That sounds like mushroom management to me. >>=20 >>> 5. IETF participants who wish to make proposals about or discuss >>> technical issues should do so in the most appropriate Working >>> Group or Area mailing list to the topic >>=20 >> That's mainly what people do. Just occasionally somebody (usually not >> a regular participant) sends a technical query to the ietf list, and >> usually gets politely redirected. I think it's great when that = happens. >>=20 >>=20 >>> 7. There should be no explicit or implicit requirement for IETF >>> leadership or any other person to be subscribed to the IETF >>> discussion list. >>=20 >> I absolutely utterly violently disagree. I must confess that the day >> I stepped down from the IAB, I dropped the ietf list, but after a = year >> or so I realised that just wasn't viable unless I only wanted to work >> in my own tiny corner of the protocol stack, and I rejoined. (There = is >> a handy delete button in my MUA, which I have always used very freely = on >> ietf@ietf.org threads.) >>=20 >> It isn't acceptable to me that IAB or IESG members would *not* keep = an >> eye on the list. >>=20 >> In summary, I think the proposed changes would change the list from >> being mainly useful but sometimes toxic, to being mainly toxic and = rarely >> useful. >>=20 >> Regards >> Brian Carpenter >>=20 >> On 17-Aug-20 13:00, internet-drafts@ietf.org = wrote: >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>=20 >>>=20 >>> Title : Rechartering the IETF Discussion List >>> Author : Mark Nottingham >>> Filename : draft-nottingham-discussion-recharter-00.txt >>> Pages : 7 >>> Date : 2020-08-16 >>>=20 >>> Abstract: >>> This document updates RFC3005, the charter of the IETF discussion >>> list. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> = https://datatracker.ietf.org/doc/draft-nottingham-discussion-recharter/ = >>>=20 >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-nottingham-discussion-recharter-00 >>> = https://datatracker.ietf.org/doc/html/draft-nottingham-discussion-recharte= r-00 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>>=20 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>=20 >>=20 >=20 > --=20 > Jay Daley > IETF Executive Director > jay@ietf.org --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_45A5479E-522A-490F-BA9A-6938BB98BAFD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 18 Aug 2020, at 04:10, Jay Daley <jay@ietf.org> = wrote:

Brian

On 18/08/2020, at 2:46 PM, Brian E Carpenter = <brian.e.carpenter@gmail.com> wrote:

This document updates = RFC3005, the charter of the IETF discussion
  list.

Then its intended status needs to be BCP.

  Comparing = its membership to a sample of other IETF mailing lists, we
  find that there are typically many members that = are not taking part
  on the IETF discussion = list:

People specialise. The = intersection count given (628) is therefore not a
useful = statistic. The intersection with the union of all WG mailing lists
would be useful. But for now, we simply do not know how many = subscribers
to at least one WG are missing from the ietf = list, and we do not know how
many subscribers to ietf are = subscribed to no WG list. Those numbers could
be = discovered, of course.

I am in the process of = determining data like this for a number of reasons and so I can give you = some interim results now.  

First the disclaimer:

* I=E2=80=99m relying on = mailman storing email addresses consistently and I have not completely = checked that it does
* I am counting address with = different +box notation as a single subscriber
* = Addresses that have been disabled by bounce processing are counted the = same as those that are not (one of the main reasons these are only = interim results)
* This data is from three weeks = ago and will have changed since then

With that in mind, the interim results = are:

1. The = membership of ietf@ was 1796 distinct subscribers 

2. There were 55,894 = distinct email addresses subscribed to mailing lists that allow open = subscription

3. = 123 subscribers to ietf@ did not subscribe to any other = list

If= I=E2=80=99m wrangling the datatracker correctly:

1608 subscribers to ietf@ietf.org
=E2=80=A6932 of whom subscribe to = at least one list for an active working group
=E2=80=A6676 do = not appear to be subscribed to any of the active working = groups

20264 subscribers to mailing = lists for active working groups. 

Colin






If I had to = guess, I'd use ietf-announce as a proxy for active participation,
and that would suggest that at (most) 1799/3037 =3D 59% of = active participants
were on the ietf list at the end of = July. That imperfect measurement is a
good deal higher = than the estimates in the draft.

4. Three weeks ago the membership of = ietf-announce was 3038

5. 800 were subscribed to ietf-announce@ and no other = list

6. 1087 = were subscribed to ietf@ but not ietf-announce@

Jay


As= I said earlier, there is evidence that only a small fraction (10%?) = of
the ietf list is interested enough in = policy/process/admin to subscribe to
lists on those = topics. So using my imperfect measurement above, we find that
at a generous estimate, 6% of IETF participants care about = policy/process/admin.

 2.  The IESG should not consider the = IETF discussion list as an
      appropriate venue for = notifying IETF participants of its actions
      or items under = consideration. 

That's not new. The formal = channel has been ietf-announce (which is not a
discussion = list) for 20+ years. True, the IESG sometimes puts the ietf list
in Cc:, but since ietf-announce is not a discussion list, = that's a natural
thing to do. Thus:

 More suitable = channels include the
      IETF Announcements list = and the GENDISPATCH Working Group,
      depending on the = notification.

is standard = operating procedure.


  3.  The IESG = should not consider the IETF discussion list as
      representative of the = broader IETF community.

Then = where can the IESG go for that? (Of course, when something reaches
a formal Last Call, we know the answer, but that is the very = last stage
in discussing a topic).

  4. =  IETF participants who wish to make proposals about or discuss = the
      IETF's direction, = policy, meetings and procedures should do so in
      GENDISPATCH or other = Working Group, if one more specific to that
      topic should exist.

Here's where it gets tricky. That = is indeed what should happen as a
proposal crystallizes. = But is the draft really saying that the plenary
discussion = list shouldn't be used for the early rounds of discussion of
an IETF-wide topic? That such topics should be discussed = *from the start
to finish* by the self-selected 6% or = fewer of participants who are process
wonks? That the rest = of the IETF will only hear about it when a Last Call
comes = out?

That sounds like mushroom management = to me.

  5.  IETF participants who wish to make = proposals about or discuss
      technical issues should = do so in the most appropriate Working
      Group or Area mailing = list to the topic

That's = mainly what people do. Just occasionally somebody (usually not
a regular participant) sends a technical query to the ietf = list, and
usually gets politely redirected. I think it's = great when that happens.


  7. =  There should be no explicit or implicit requirement for IETF
      leadership or any other = person to be subscribed to the IETF
      discussion list.

I absolutely utterly violently = disagree. I must confess that the day
I stepped down from = the IAB, I dropped the ietf list, but after a year
or so I = realised that just wasn't viable unless I only wanted to work
in my own tiny corner of the protocol stack, and I rejoined. = (There is
a handy delete button in my MUA, which I have = always used very freely on
ietf@ietf.org threads.)

It isn't acceptable to me that IAB or IESG members would = *not* keep an
eye on the list.

In summary, I think the proposed changes would change the = list from
being mainly useful but sometimes toxic, to = being mainly toxic and rarely
useful.

Regards
  Brian Carpenter

On 17-Aug-20 13:00, internet-drafts@ietf.org wrote:

A New = Internet-Draft is available from the on-line Internet-Drafts = directories.


       Title =           : = Rechartering the IETF Discussion List
       Author =          : Mark = Nottingham
Filename =        : = draft-nottingham-discussion-recharter-00.txt
Pages =           : 7
= Date =            : = 2020-08-16

Abstract:
  This document updates RFC3005, the charter of the = IETF discussion
  list.


The IETF datatracker status page for this = draft is:
https://datatracker.ietf.org/doc/draft-nottingham-discussion-re= charter/

There are also htmlized = versions available at:
https://tools.ietf.org/html/draft-nottingham-discussion-rechart= er-00
https://datatracker.ietf.org/doc/html/draft-nottingham-discussi= on-recharter-00


Please note = that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at = tools.ietf.org.

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt



-- 
Jay = Daley
IETF Executive Director
jay@ietf.org



-- 
Colin Perkins
https://csperkins.org/




= --Apple-Mail=_45A5479E-522A-490F-BA9A-6938BB98BAFD-- From nobody Tue Aug 18 09:50:01 2020 Return-Path: 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 29F753A0F68 for ; Tue, 18 Aug 2020 09:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 7OIVPDKnIhyk for ; Tue, 18 Aug 2020 09:49:58 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 887A53A0F65 for ; Tue, 18 Aug 2020 09:49:58 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id B14F82C16D6; Tue, 18 Aug 2020 12:49:57 -0400 (EDT) Date: Tue, 18 Aug 2020 12:49:57 -0400 From: Viktor Dukhovni To: gendispatch@ietf.org Message-ID: <20200818164957.GA86346@straasha.imrryr.org> Reply-To: gendispatch@ietf.org References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 16:50:00 -0000 On Tue, Aug 18, 2020 at 11:34:52AM +0000, Salz, Rich wrote: > It is noisy, repetitive, and sometimes not useful. So are humans. Just > because something’s not always good doesn’t mean it’s bad or broken > and needs to be fixed. Openness is worth it, and it comes with costs > we should be willing to pay. > > I dislike this draft and prefer it gets abandoned. +1. I concur, a single recent contentious topic is not sufficient grounds to throw out the baby with the bathwater. I imagine most subscribers have emaill clients that group messages by thread. It is then quite easy to skip threads that cease to be worth reading. -- Viktor. From nobody Tue Aug 18 10:13:53 2020 Return-Path: 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 208583A03EC for ; Tue, 18 Aug 2020 10:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 7k-73oSYqqX2 for ; Tue, 18 Aug 2020 10:13:51 -0700 (PDT) Received: from bisque.elm.relay.mailchannels.net (bisque.elm.relay.mailchannels.net [23.83.212.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A227D3A012A for ; Tue, 18 Aug 2020 10:13:50 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A9B4692197F; Tue, 18 Aug 2020 17:13:49 +0000 (UTC) Received: from pdx1-sub0-mail-a81.g.dreamhost.com (100-96-5-126.trex.outbound.svc.cluster.local [100.96.5.126]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 47121921900; Tue, 18 Aug 2020 17:13:48 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a81.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Tue, 18 Aug 2020 17:13:49 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Spot-Tart: 316e464b71350797_1597770828769_981893296 X-MC-Loop-Signature: 1597770828769:1388233858 X-MC-Ingress-Time: 1597770828768 Received: from pdx1-sub0-mail-a81.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a81.g.dreamhost.com (Postfix) with ESMTP id A290E7E705; Tue, 18 Aug 2020 10:13:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to:content-transfer-encoding; s=cryptonector.com; bh=O f0UmTyRJg4bXqINUyQIhaJYaEU=; b=AtqiNPdpHrmDT6dGTrIaRjhshnQ6I3Jwj GnuCxwmXhvYImuBMZS4kZiNOdSz9UlMPwjndeYWhpw8dhrKt7GjYfoQAKjKi3CTG SZhHvImiBRzmpKZi4gprSdLxaMvfpFeQ0rlSm5YCfjrozXYvQzzuFlXASuuA7rtH a6iPXa1uqE= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a81.g.dreamhost.com (Postfix) with ESMTPSA id 3558A7E706; Tue, 18 Aug 2020 10:13:46 -0700 (PDT) Date: Tue, 18 Aug 2020 12:13:44 -0500 X-DH-BACKEND: pdx1-sub0-mail-a81 From: Nico Williams To: gendispatch@ietf.org Message-ID: <20200818171343.GP3100@localhost> References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <20200818164957.GA86346@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200818164957.GA86346@straasha.imrryr.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedruddtiedgkeelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggugfgjfgesthekredttderjeenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpeegvdeivdeggfdthfetgffhueffgeelgfeghfdvgfdtfffhveffieehffeiuedufeenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 17:13:52 -0000 On Tue, Aug 18, 2020 at 12:49:57PM -0400, Viktor Dukhovni wrote: > On Tue, Aug 18, 2020 at 11:34:52AM +0000, Salz, Rich wrote: > > It is noisy, repetitive, and sometimes not useful. So are humans. Jus= t > > because something=E2=80=99s not always good doesn=E2=80=99t mean it=E2= =80=99s bad or broken > > and needs to be fixed. Openness is worth it, and it comes with costs > > we should be willing to pay. > >=20 > > I dislike this draft and prefer it gets abandoned. >=20 > +1. I concur, a single recent contentious topic is not sufficient > grounds to throw out the baby with the bathwater. I imagine most > subscribers have emaill clients that group messages by thread. It is > then quite easy to skip threads that cease to be worth reading. +1. Hard cases make bad law and all that. From nobody Tue Aug 18 10:26:38 2020 Return-Path: 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 5EF633A0820; Tue, 18 Aug 2020 10:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 KYqByQpRxDQc; Tue, 18 Aug 2020 10:26:35 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ECFA3A082E; Tue, 18 Aug 2020 10:26:35 -0700 (PDT) Received: from p200300dee72156000cd8e88136bbc164.dip0.t-ipconnect.de ([2003:de:e721:5600:cd8:e881:36bb:c164]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1k85NY-0006J0-9j; Tue, 18 Aug 2020 19:26:32 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mirja Kuehlewind In-Reply-To: <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> Date: Tue, 18 Aug 2020 19:26:31 +0200 Cc: Mark Nottingham , "gendispatch@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.3608.80.23.2.2) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1597771595;793ff3bf; X-HE-SMSGID: 1k85NY-0006J0-9j Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 17:26:37 -0000 For me the openness principle of the IETF also includes that the barrier = to participation must be kept low, meaning that the we should help to = reduce the time commitment people have to make to work productively = whenever possible. In that sense I don=E2=80=99t think the ietf list = currently serves us well and trying to use more specific lists as much = as possible seems to me a good proposal for discussion. Rich, I really don=E2=80=99t know what you mean by "this draft should = get abandoned". Part of this openness is that every one can submit (and = maintain) individual drafts. If there is support in the community to = further work on the proposal is a different question but I think = that=E2=80=99s what we are currently trying to figure out. > On 18. Aug 2020, at 13:34, Salz, Rich = wrote: >=20 >> I don't agree with the characterisation of the list in its current = form as 'mainly useful but sometimes toxic' -- 'mainly toxic and rarely = useful' is much more apt. I'd be interested to hear what others think, = though. > =20 > I think the IETF list is rarely toxic. Maybe since I grew up on Usenet = and xml-dev I have a higher tolerance, but I can=E2=80=99t recall a = toxic thread other than the language one. And even then, my feelings are = more sensitized because I participate perhaps (and was just recently = =E2=80=9Cburned=E2=80=9D by the same topic over in an open source = project). So I=E2=80=99m curious what other topic threads others = consider toxic. > =20 > It is noisy, repetitive, and sometimes not useful. So are humans. Just = because something=E2=80=99s not always good doesn=E2=80=99t mean it=E2=80=99= s bad or broken and needs to be fixed. Openness is worth it, and it = comes with costs we should be willing to pay. > =20 > I dislike this draft and prefer it gets abandoned. > =20 > /r$ > =20 > --=20 > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch From nobody Tue Aug 18 10:31:34 2020 Return-Path: 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 CA8353A086C for ; Tue, 18 Aug 2020 10:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 zST4852RP3w0 for ; Tue, 18 Aug 2020 10:31:31 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B0E3A086A for ; Tue, 18 Aug 2020 10:31:31 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QF90FBYYSOJ7J@wwwlocal.goatley.com> for gendispatch@ietf.org; Tue, 18 Aug 2020 12:31:31 -0500 (CDT) Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QF900KAJSNKFE@trixy.bergandi.net> for gendispatch@ietf.org; Tue, 18 Aug 2020 10:30:56 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Tue, 18 Aug 2020 10:30:56 -0700 Date: Tue, 18 Aug 2020 10:31:29 -0700 From: Dan Harkins In-reply-to: <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> To: gendispatch@ietf.org Message-id: <61a4b456-972e-2734-e3fc-35be9270d090@lounge.org> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Vy7JK6nSxXDax/mz1lWskA)" Content-language: en-US User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local) References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> X-PMAS-Software: PreciseMail V3.3 [200817] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 17:31:33 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Vy7JK6nSxXDax/mz1lWskA) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 8BIT On 8/18/20 4:34 AM, Salz, Rich wrote: > > I don't agree with the characterisation of the list in its current > form as 'mainly useful but sometimes toxic' -- 'mainly toxic and > rarely useful' is much more apt. I'd be interested to hear what > others think, though. > > I think the IETF list is rarely toxic. Maybe since I grew up on Usenet > and xml-dev I have a higher tolerance, but I can’t recall a toxic > thread other than the language one. And even then, my feelings are > more sensitized because I participate perhaps (and was just recently > “burned” by the same topic over in an open source project). So I’m > curious what other topic threads others consider toxic. >   I agree. These contentious issues happen so infrequently that I'm having trouble recalling another one (although I seem to remember getting angry in the past over ietf traffic). > It is noisy, repetitive, and sometimes not useful. So are humans. Just > because something’s not always good doesn’t mean it’s bad or broken > and needs to be fixed. Openness is worth it, and it comes with costs > we should be willing to pay. >   That is a great way to put it! > I dislike this draft and prefer it gets abandoned. >   Agree. I think the recent flare-up shows that something needs to be done vis-a-vis power and its (ab)use by IETF leadership but this draft isn't it.   regards,   Dan. --Boundary_(ID_Vy7JK6nSxXDax/mz1lWskA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: 8BIT
On 8/18/20 4:34 AM, Salz, Rich wrote:

I don't agree with the characterisation of the list in its current form as 'mainly useful but sometimes toxic' -- 'mainly toxic and rarely useful' is much more apt. I'd be interested to hear what others think, though.

 

I think the IETF list is rarely toxic. Maybe since I grew up on Usenet and xml-dev I have a higher tolerance, but I can’t recall a toxic thread other than the language one. And even then, my feelings are more sensitized because I participate perhaps (and was just recently “burned” by the same topic over in an open source project). So I’m curious what other topic threads others consider toxic.


  I agree. These contentious issues happen so infrequently that I'm having trouble
recalling another one (although I seem to remember getting angry in the past over
ietf traffic).


It is noisy, repetitive, and sometimes not useful. So are humans. Just because something’s not always good doesn’t mean it’s bad or broken and needs to be fixed. Openness is worth it, and it comes with costs we should be willing to pay.


  That is a great way to put it!

I dislike this draft and prefer it gets abandoned.


  Agree. I think the recent flare-up shows that something needs to be done
vis-a-vis power and its (ab)use by IETF leadership but this draft isn't it.

  regards,

  Dan.


 --Boundary_(ID_Vy7JK6nSxXDax/mz1lWskA)-- From nobody Tue Aug 18 10:52:24 2020 Return-Path: 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 2E3673A08AE for ; Tue, 18 Aug 2020 10:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Unjb-JWAEusx for ; Tue, 18 Aug 2020 10:52:19 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DCE73A09FD for ; Tue, 18 Aug 2020 10:52:17 -0700 (PDT) Received: from xse6.mail2web.com ([66.113.196.6] helo=xse.mail2web.com) by mx166.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1k85mD-000q00-Mk for gendispatch@ietf.org; Tue, 18 Aug 2020 19:52:07 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4BWHzB6SRVz1WJ8 for ; Tue, 18 Aug 2020 10:32:06 -0700 (PDT) Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1k85Sw-0002o3-PO for gendispatch@ietf.org; Tue, 18 Aug 2020 10:32:06 -0700 Received: (qmail 10690 invoked from network); 18 Aug 2020 17:32:06 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.161]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 18 Aug 2020 17:32:06 -0000 To: gendispatch@ietf.org, Viktor Dukhovni References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <20200818164957.GA86346@straasha.imrryr.org> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <090f2c01-6494-7be3-4b99-280576733f35@huitema.net> Date: Tue, 18 Aug 2020 10:32:05 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200818164957.GA86346@straasha.imrryr.org> Content-Type: multipart/alternative; boundary="------------DD5075A464F2091C5C632689" Content-Language: en-US X-Originating-IP: 66.113.196.6 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.6/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.6/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Uc1Z+hCSaILZIw3vLzlsGSpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDtLSXJfCfZOnWpXE1/I0nj9Xt FNSzkMWnDricnMrpFJp1U9eB0Q4R7I+7zpX2G0VqQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEzBCgqe539x2oAbbqp81Hae42Vki7412dpbhrD2d47zbC3VvU djSCswikK/licfX+oIF6uBSWByrPG2Vxuo/vVPllrFEbCkMryfcYCsgMUJObfBQoU3roWy2GH1DY sAiH3gousbgNfxi2R3uFLvZP/HBXvrLBlKCVRjjdPbjQ4HnBNho1Lszw5OO01yYoll8q2UgzFF+j HNSbIoW1Q++Wvj3dKxLhoxcmaInYbR5vlqFg3eKzPG9E5MikC2dVXWcpK172i/E5sOgbaCtBiSIx 1XwCY8vmv+JqOVJamBHfOGVwjn7Xut/lXagsodd5qqODTFiwcpU4fyz75jxpU98RPGiH1Wgh6RAe nBR+licROGZNFSBymhtbd6ygEffuU1+3Lf6cmU/99wDQedNhMKpgrTWpQLVdzjtZCTxsRhzNiQvB H1fP3YU+2XWwKzL04bcfIM8y5lBnEodWLzcHAfJdGZXked+P+aSZU/EB7YnRWs2LBDMrD7q/cJog wbqzsuokuq9ANeWZ2dKxp9LOYGODIWre/hsBBxzR0ZxLcHZ9dOhqvjPZ9Vt69J4F5yqOvmzXlboT xOgrGs9sXb7WGYNHqZ6UQuUYDNtOodMW0lEIMJ/2LG8Qb6d2S6jBVW8serS5JOYIJd4MvQ0Nf4Ec bvHO1diDanHV9KirFAIIecsyj+YNTo81GR+jDXFsz/ZQnbbTizvwlZsrbltGiZoUh+c+5pFVgpT1 b21uZVckGp0ccOa2XhkGbmsUNPNkere1WheNsVXmhO8BzADiszcWR9bz/SDtF09JpSbuuCeiIDK0 C/0= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 17:52:22 -0000 This is a multi-part message in MIME format. --------------DD5075A464F2091C5C632689 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/18/2020 9:49 AM, Viktor Dukhovni wrote: > On Tue, Aug 18, 2020 at 11:34:52AM +0000, Salz, Rich wrote: > >> It is noisy, repetitive, and sometimes not useful. So are humans. Just= >> because something=E2=80=99s not always good doesn=E2=80=99t mean it=E2= =80=99s bad or broken >> and needs to be fixed. Openness is worth it, and it comes with costs >> we should be willing to pay. >> >> I dislike this draft and prefer it gets abandoned. > +1. I concur, a single recent contentious topic is not sufficient > grounds to throw out the baby with the bathwater. I imagine most > subscribers have emaill clients that group messages by thread. It is > then quite easy to skip threads that cease to be worth reading. I am not entirely convinced by Mark's draft either. My personal assessment is that we have many problems: * The IETF list acts as the offline general assembly, but without any rules of order. We would not run a meeting of 1000 people without any such rules, and for example we use mike queues and time limits during the plenary. The lack of order leads to poor behavior and reduced utility= =2E * The IETF list also acts as the IETF lobby, a place that newcomers might join in order to sense the pulse of the organization. But we are conducting a permanent and sometimes very loud general assembly in the lobby, and that scares visitors away. * To expand on the previous point, the tolerance for loud discussions naturally selects for loud spoken and loudness tolerant individuals, typically oldtimers. It turns away other types of participants, contributing to lack of renewal and lack of diversity in the organization= =2E * As Mark points out, the list membership is a fraction of the IETF participants, which makes it a rather unrepresentative general assembly. But that may well be a consequence of the other issues. Mark's proposal addresses the "rules of order" issue by directing discussions to the gendispatch WG, and then possibly to specialized WG. The advantage is that WG chairs can and do impose discussion rules. We have examples that it works, e.g., moving the RFC-ED discussion from the IETF list to a specialized group. But Mark's proposal also does away with any notion of an online general assembly -- the IETF list is left to its own devices, some kind of playground for people who like loud debates, and the IESG is told that it just does not have to listen. That seems sub-optimal, because feedback is indeed useful. If I am right -- :-) -- the main missing component is some kind of "rules of order" for the IETF list, similar to the mike lines and time limits that we have in working groups or in the physical plenary. This requires some authority to enforce the rules, an authority that should be separate from the IAB/IESG leadership if we want an avenue of feedback for that leadership. We may also consider not washing our dirty laundry in the front lobby, i.e., separating the "social discussion" and "plenary" functions. -- Christian Huitema --------------DD5075A464F2091C5C632689 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/18/2020 9:49 AM, Viktor Dukhovni wrote:

On Tue, Aug 18, 2020 at 11:34:52AM +0000, Salz, Rich wrote:


It is noisy, repetitive, and sometimes not useful. So are humans. Just
because something’s not always good doesn’t mean it’s bad or broken
and needs to be fixed. Openness is worth it, and it comes with costs
we should be willing to pay.

I dislike this draft and prefer it gets abandoned.

+1.  I concur, a single recent contentious topic is not sufficient
grounds to throw out the baby with the bathwater.  I imagine most
subscribers have emaill clients that group messages by thread.  It is
then quite easy to skip threads that cease to be worth reading.


I am not entirely convinced by Mark's draft either. My personal assessment is that we have many problems:

* The IETF list acts as the offline general assembly, but without any rules of order. We would not run a meeting of 1000 people without any such rules, and for example we use mike queues and time limits during the plenary. The lack of order leads to poor behavior and reduced utility.

* The IETF list also acts as the IETF lobby, a place that newcomers might join in order to sense the pulse of the organization. But we are conducting a permanent and sometimes very loud general assembly in the lobby, and that scares visitors away.

* To expand on the previous point, the tolerance for loud discussions naturally selects for loud spoken and loudness tolerant individuals, typically oldtimers. It turns away other types of participants, contributing to lack of renewal and lack of diversity in the organization.

* As Mark points out, the list membership is a fraction of the IETF participants, which makes it a rather unrepresentative general assembly. But that may well be a consequence of the other issues.

Mark's proposal addresses the "rules of order" issue by directing discussions to the gendispatch WG, and then possibly to specialized WG. The advantage is that WG chairs can and do impose discussion rules. We have examples that it works, e.g., moving the RFC-ED discussion from the IETF list to a specialized group. But Mark's proposal also does away with any notion of an online general assembly -- the IETF list is left to its own devices, some kind of playground for people who like loud debates, and the IESG is told that it just does not have to listen. That seems sub-optimal, because feedback is indeed useful.

If I am right -- :-) -- the main missing component is some kind of "rules of order" for the IETF list, similar to the mike lines and time limits that we have in working groups or in the physical plenary. This requires some authority to enforce the rules, an authority that should be separate from the IAB/IESG leadership if we want an avenue of feedback for that leadership.

We may also consider not washing our dirty laundry in the front lobby, i.e., separating the "social discussion" and "plenary" functions.

-- Christian Huitema

--------------DD5075A464F2091C5C632689-- From nobody Tue Aug 18 10:53:46 2020 Return-Path: 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 BE4293A08B7 for ; Tue, 18 Aug 2020 10:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=akamai.com 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 YsZjnB_SAQFg for ; Tue, 18 Aug 2020 10:53:43 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 908CA3A08B0 for ; Tue, 18 Aug 2020 10:53:43 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07IHqoqS001136; Tue, 18 Aug 2020 18:53:43 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=4G3JK9lKfVTbsRpw2oEdmK2Q0UMibfM2LrQr2pEwqYU=; b=Us9+w97ANVq6kI3moH99AAG8T9H6RoTQ+/wAiZRjEd4yd50rbKbfgjJ947nn2C7/mA7W CMH7ijaiX2yeWyO0iQUj6BHj5/Qb4H3CSY5gBOx//+rO7O6pJ7hBzF4R6DlhJhL2c6mu 4cCNWSQRQgkqYeocWSwicZJ5NwZpn3x+/y8J6sqWiVjvyfoA6Llc+kbewVfPEJ7EWdfr +qx62Kqq9vYopsspXQ3FIXnLFnWDRNAwevGlx3BPHe8Cxiy6pHL7GSJE3B61AeGYNHKx iaN2KhWZG90qhJAtXJ9y+85pDg5KTQsZ2bEs9lh7/NT2tYt7j8w7/u2DU3PsMxi+6MSK ng== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 3304hb92j7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Aug 2020 18:53:43 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 07IHpBTR018682; Tue, 18 Aug 2020 13:53:41 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 32xb1xuhdx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 18 Aug 2020 13:53:41 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 18 Aug 2020 13:53:41 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1497.006; Tue, 18 Aug 2020 13:53:40 -0400 From: "Salz, Rich" To: Mirja Kuehlewind CC: Mark Nottingham , "gendispatch@ietf.org" Thread-Topic: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt Thread-Index: AQHWdQnnOx27rqM9kEa/cTAscvAiaKk9n7iAgAADR4CAABoZAIAApU+A///EhwA= Date: Tue, 18 Aug 2020 17:53:40 +0000 Message-ID: <83030C9D-DD90-4F19-8AF9-CC91C3738319@akamai.com> References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.116.150] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-18_12:2020-08-18, 2020-08-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 malwarescore=0 spamscore=0 mlxlogscore=601 bulkscore=0 phishscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008180123 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-18_12:2020-08-18, 2020-08-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 impostorscore=0 malwarescore=0 priorityscore=1501 suspectscore=0 adultscore=0 mlxlogscore=552 bulkscore=0 lowpriorityscore=0 phishscore=0 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008180124 Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 17:53:45 -0000 PiAgICBSaWNoLCBJIHJlYWxseSBkb27igJl0IGtub3cgd2hhdCB5b3UgbWVhbiBieSAidGhpcyBk cmFmdCBzaG91bGQgZ2V0IGFiYW5kb25lZCIuIA0KDQpJIHdhbnQgdGhpcyB0byBub3QgYmUgYWR2 YW5jZWQgdG8gYSBXRy4gIFNvcnJ5IGlmIEkgdXNlZCB0aGUgd3JvbmcgdGVybSBmb3IgdGhhdCBh Y3Rpb24uDQoNCg0KDQo= From nobody Tue Aug 18 11:25:01 2020 Return-Path: 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 7C5223A0983 for ; Tue, 18 Aug 2020 11:24:59 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=gmail.com 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 E49FsBZ7WZuQ for ; Tue, 18 Aug 2020 11:24:57 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2153A095F for ; Tue, 18 Aug 2020 11:24:57 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id v6so16993061ota.13 for ; Tue, 18 Aug 2020 11:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Zs+PPZulr/0vXc0ZEsD8CUHy1RaxZlBrBNo8pqMqokw=; b=QqaQdJ7mA1JFtaOA42nYJNfT7WKhHKAF9k4xWgckT7mt2pKUA5XP8WqavawoC4fUOt RAPMZp10d0jcxAJLAx7w3Ya7tLgIkDa/zpGXwR9Ub1ESKQaDwL+bL1NK/2ngEHy5fajh ZK3VSZS1FDPovAa486hZdO3oOUJpW9mr0rznL6xCo+pgcYAT4303gP6Wpj9tU8GgOuU6 874KnS4N6j9FU3oxZ0RUu8e6q5MKb0h2qHUT+Ds982CkNkukmlapdnvGvJdri4mB8SSc gtwGUyeK1S3yYCjPmNbQP0HPhch0VM61FLD0dKvUWugrylIeL83bR7oL9/baRKoZNnV8 j9Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Zs+PPZulr/0vXc0ZEsD8CUHy1RaxZlBrBNo8pqMqokw=; b=kkyftvhGB2UJEeOGa+TuPb8gpuOk1WFDBRHwogwRaQoo+UHQZvSHqRDkvBXD5FoLmG bvcC3zrP9fwSN2TcPgEFT0shp7Rpi8KPzsmfvBexNzAC52R+nsyvX0hIOlWB4QAp6NPZ TeCH4IqcJXnF/Ire2MucDmmNQnpeE96yopR7VlvnpdWZdEOO/QhUTakp9Bre+bUg0BX3 vWuZQsgHFnocUzR9YvsL+O7TgCL9GFSDj64jyeuyX3f6xhR9Hs00eBjd490XPRJS1X81 zlNEDpsMUVFgoBf3buzXwoEHGi7PEHishqm2AK6Wkt5ifv3J0/0viMLgA8pGMzgy3hyc hnOg== X-Gm-Message-State: AOAM532JgNM8X7CrvoZ0vqKqaeZqjHqXZMpfklT92G2CjQiIbk+Q5stO VvaeBsHtqRIDFmGe4keAzIkVkXiDInPupzRhD9tezcnm X-Google-Smtp-Source: ABdhPJyT0JmpP8IrImsKcjBBGQurwfpMCq4j5YeYKTfHM6/n7znF3G58lZIvCvkz2gaj/TTvXRmrjxAp6RjOFfTx5xQ= X-Received: by 2002:a9d:7283:: with SMTP id t3mr15396209otj.303.1597775097028; Tue, 18 Aug 2020 11:24:57 -0700 (PDT) MIME-Version: 1.0 References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> In-Reply-To: From: Mary Barnes Date: Tue, 18 Aug 2020 13:24:30 -0500 Message-ID: To: Mirja Kuehlewind Cc: "Salz, Rich" , Mark Nottingham , "gendispatch@ietf.org" Content-Type: multipart/alternative; boundary="00000000000016e60b05ad2b01ba" Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 18:24:59 -0000 --00000000000016e60b05ad2b01ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 18, 2020 at 12:26 PM Mirja Kuehlewind wrote: > For me the openness principle of the IETF also includes that the barrier > to participation must be kept low, meaning that the we should help to > reduce the time commitment people have to make to work productively > whenever possible. In that sense I don=E2=80=99t think the ietf list curr= ently > serves us well and trying to use more specific lists as much as possible > seems to me a good proposal for discussion. > [MB] I don't believe most people come first to the IETF discussion list when they are interested in participating in IETF - announcement list, yes. In my experience, people come to IETF because they have a specific technical area that they want to learn more about and ideally contribute to. People would generally subscribe to various WG (and area) mailing lists. People might join the IETF discussion list just to get the broader view, but that would be secondary in my experience. I long, long ago switched my subscription to the IETF discussion list to a different email address so it didn't distract me from the real IETF technical work. Definitely, for topics that fit the scope of other groups, discussions can be directed there. I think there are a whole lot of other things that are barriers (or deterrents) to participation than the IETF discussion list and I haven't found it to be any more brutal (or toxic) than what one can experience in WG sessions. It doesn't take long for the average person to figure out that the discussion list can be a free for all and as others have pointed out, it's pretty easy to redirect these messages so that they're not getting in the way of higher priority IETF activities. [/MB] > > Rich, I really don=E2=80=99t know what you mean by "this draft should get > abandoned". Part of this openness is that every one can submit (and > maintain) individual drafts. If there is support in the community to > further work on the proposal is a different question but I think that=E2= =80=99s > what we are currently trying to figure out. > > > > > On 18. Aug 2020, at 13:34, Salz, Rich > wrote: > > > >> I don't agree with the characterisation of the list in its current for= m > as 'mainly useful but sometimes toxic' -- 'mainly toxic and rarely useful= ' > is much more apt. I'd be interested to hear what others think, though. > > > > I think the IETF list is rarely toxic. Maybe since I grew up on Usenet > and xml-dev I have a higher tolerance, but I can=E2=80=99t recall a toxic= thread > other than the language one. And even then, my feelings are more sensitiz= ed > because I participate perhaps (and was just recently =E2=80=9Cburned=E2= =80=9D by the same > topic over in an open source project). So I=E2=80=99m curious what other = topic > threads others consider toxic. > > > > It is noisy, repetitive, and sometimes not useful. So are humans. Just > because something=E2=80=99s not always good doesn=E2=80=99t mean it=E2=80= =99s bad or broken and > needs to be fixed. Openness is worth it, and it comes with costs we shoul= d > be willing to pay. > > > > I dislike this draft and prefer it gets abandoned. > > > > /r$ > > > > -- > > Gendispatch mailing list > > Gendispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/gendispatch > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > --00000000000016e60b05ad2b01ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 18, 2020 at 12:26 PM Mirja Ku= ehlewind <ietf@kuehlewind.net= > wrote:
For me the openness principle of the IETF also inclu= des that the barrier to participation must be kept low, meaning that the we= should help to reduce the time commitment people have to make to work prod= uctively whenever possible. In that sense I don=E2=80=99t think the ietf li= st currently serves us well and trying to use more specific lists as much a= s possible seems to me a good proposal for discussion.
[MB] I don't believe most people come first to the IETF discussion lis= t when they are interested in participating in IETF - announcement list, ye= s.=C2=A0 =C2=A0In my experience, people come to IETF because they have a sp= ecific technical area that they want to learn more about and ideally contri= bute to.=C2=A0 People would generally subscribe to various WG (and area) ma= iling lists.=C2=A0 People might join the IETF discussion list just to get t= he broader view, but that would be secondary in my experience.=C2=A0 =C2=A0= I long, long ago switched my subscription to the IETF discussion list to a= different email address so it didn't distract me from the real IETF te= chnical work.=C2=A0 Definitely, for topics that fit the scope of other grou= ps, discussions can be directed there.=C2=A0 I think there are a whole lot = of other things that are barriers (or deterrents) to participation than the= IETF discussion list and I haven't found it to be any more brutal (or = toxic) than what one can experience in WG sessions.=C2=A0 It doesn't ta= ke long for the average person to figure out that the discussion list can b= e a free for all and as others have pointed out, it's pretty easy to re= direct these messages so that they're not getting in the way of higher = priority IETF activities.=C2=A0 [/MB]

Rich, I really don=E2=80=99t know what you mean by "this draft should = get abandoned". Part of this openness is that every one can submit (an= d maintain) individual drafts. If there is support in the community to furt= her work on the proposal is a different question but I think that=E2=80=99s= what we are currently trying to figure out.



> On 18. Aug 2020, at 13:34, Salz, Rich <rsalz=3D40akamai.com@dmarc.ietf.org> wrote:
>
>> I don't agree with the characterisation of the list in its cur= rent form as 'mainly useful but sometimes toxic' -- 'mainly tox= ic and rarely useful' is much more apt. I'd be interested to hear w= hat others think, though.
>=C2=A0
> I think the IETF list is rarely toxic. Maybe since I grew up on Usenet= and xml-dev I have a higher tolerance, but I can=E2=80=99t recall a toxic = thread other than the language one. And even then, my feelings are more sen= sitized because I participate perhaps (and was just recently =E2=80=9Cburne= d=E2=80=9D by the same topic over in an open source project). So I=E2=80=99= m curious what other topic threads others consider toxic.
>=C2=A0
> It is noisy, repetitive, and sometimes not useful. So are humans. Just= because something=E2=80=99s not always good doesn=E2=80=99t mean it=E2=80= =99s bad or broken and needs to be fixed. Openness is worth it, and it come= s with costs we should be willing to pay.
>=C2=A0
> I dislike this draft and prefer it gets abandoned.
>=C2=A0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0/r$
>=C2=A0
> --
> Gendispatch mailing list
> Gendispatch@= ietf.org
> https://www.ietf.org/mailman/listinfo/gendispa= tch

--
Gendispatch mailing list
Gendispatch@ietf.= org
https://www.ietf.org/mailman/listinfo/gendispatch
--00000000000016e60b05ad2b01ba-- From nobody Tue Aug 18 15:43:02 2020 Return-Path: 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 E41DE3A0E8A; Tue, 18 Aug 2020 15:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=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=gmail.com 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 zD5Shh7utK2C; Tue, 18 Aug 2020 15:42:59 -0700 (PDT) Received: from mail-pg1-x541.google.com (mail-pg1-x541.google.com [IPv6:2607:f8b0:4864:20::541]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35C513A0E8B; Tue, 18 Aug 2020 15:42:59 -0700 (PDT) Received: by mail-pg1-x541.google.com with SMTP id v15so10423963pgh.6; Tue, 18 Aug 2020 15:42:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=N1UMzlMb3dKdy+3PFgU7APs5iSGTVtbbBcpL/6tPVtI=; b=iJQYhws1GdzsxwSjM5bcrybZdQGl4nILZCdhU+k8fQvpEAzJdelvB7vJC0d9Q6dLK6 dXMmiWYTY02o0CzUXRV98mBcIdoQPbanEyFfeh97QcRrhz6mqKUFlsJiYg854eJdCEps YSwzgjyXKizNfUPht/MrspnEeyCoklZ8y9XbvaoJZCi8jdCAVxW0GYeqy9kBg6tXGYF8 Nj4xVYeeVq1/7m9Z206MK9SNHplfBV1qPOsLaC5X0aNPwlSgvoV4j/k7b+yues0gyrJX 8jras9sxsTloErgTpLsI9In+8ANpYA2Dwdwnvk/P7cb5+yZs3xvX7/gu6DvtlBfe+SaE 8CKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=N1UMzlMb3dKdy+3PFgU7APs5iSGTVtbbBcpL/6tPVtI=; b=e2dGo+qd7GhaHfoaeU133XfUbLsnAg+HptLT0+ZK8pBduF1TREYlm3sWBRISQ6YUGG AQ3a1v+lrrcXc7ae8uwtXzVXHwow/n3Wbb73wevHfHUIvZ6qHBB0986g5cZoarYik0RP eBoCe9kOJg1ZlqhdAMzHhvPreb77zlJOJyYAqOFMrMAismES8onGO4TkaqWtnsDEXmEz 8DlaQPTbSFEXNdw2MRsXHi7VTTTII930MjCNkLsp18ahjM3Sces74f/6nCEJJ1g/JWR3 MAbldtXw3C+vK87YKmI82nl1f4YHwsBTHYCQnr9DVj38jrr/oxnBlJCRxOuRCMABtnz3 wdEw== X-Gm-Message-State: AOAM531AOs/tABuOgoLOt/yy/dV+bfYx3XriZ/TC3HJqmroRC8sKZe5X ZmZK7pEtKCgIDSmCCvqVhWCFs9KFTPDcEg== X-Google-Smtp-Source: ABdhPJwz8jVkUSyozm6GEnGjYTQVGhl4mi2jMNUiNI518lt+qDvoIjZikrzjMbFI3kFyQ06YH81e1w== X-Received: by 2002:a63:a84b:: with SMTP id i11mr14660724pgp.79.1597790578324; Tue, 18 Aug 2020 15:42:58 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id e4sm25336013pfd.204.2020.08.18.15.42.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Aug 2020 15:42:57 -0700 (PDT) To: Colin Perkins , Jay Daley Cc: gendispatch@ietf.org References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <256AB2A2-3936-4D72-95D2-12FFBB893326@csperkins.org> From: Brian E Carpenter Message-ID: Date: Wed, 19 Aug 2020 10:42:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <256AB2A2-3936-4D72-95D2-12FFBB893326@csperkins.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 22:43:01 -0000 On 19-Aug-20 04:01, Colin Perkins wrote: =2E.. > If I=E2=80=99m wrangling the datatracker correctly: >=20 > 1608 subscribers to=C2=A0ietf@ietf.org > =E2=80=A6932 of whom subscribe to at least one list for an active worki= ng group > =E2=80=A6676 do not appear to be subscribed to any of the active workin= g groups >=20 > 20264 subscribers to mailing lists for active working groups.=C2=A0 Interesting. But without further analysis of people who use different addresses for different lists, and how many of those addresses are dormant, it's not clear what the definitive conclusions should be. At face value, 932/20264 would rather seem to validate my claim that less than 10% of participants are interested in plenary matters. Brian From nobody Tue Aug 18 15:50:59 2020 Return-Path: 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 01CA03A0EC1; Tue, 18 Aug 2020 15:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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=csperkins.org 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 XOORLYzhLI2X; Tue, 18 Aug 2020 15:50:55 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C483A0EBC; Tue, 18 Aug 2020 15:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=83kFs552o4I5+nbncrZw6A3555oVmYq4zp6cCFpT6AI=; b=QjODaUaNp6OZwMmRESxfIcmT70 E8y63JRBxU9KzPKzEWXP6UfLP/MPg5U2xVgv1a5mJmrbux3k/fKZdzCeIYi7+exbMipz28oAYtaNl xL0z47MX7/wzlL9dk2XOJ5mySQL6FsNMttO3YHsehc6w0Anv/sr1M/3d5k097ChRYPPXgR+7bq/wX sAEQqXCai/3DYwDVkC7PHYGFBBcdvhLVc30rLBBBhv+k4QTs8AhTWDekfuG5cVDEHjbbeOp8PEazB isJv26XyFoUURVv+stbg4Yyi8KB1jabYbZGRRRQeiNlwZYHiwXj40nWCAmDZaKtf1qjVdtlcGZhQY q2UMdU0g==; Received: from [81.187.2.149] (port=44953 helo=[192.168.0.80]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1k8ARR-0006j2-FC; Tue, 18 Aug 2020 23:50:53 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) From: Colin Perkins In-Reply-To: Date: Tue, 18 Aug 2020 23:50:52 +0100 Cc: Jay Daley , gendispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <02A012DC-706E-44F1-8CEB-39F8F6FC40C1@csperkins.org> References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <256AB2A2-3936-4D72-95D2-12FFBB893326@csperkins.org> To: Brian E Carpenter X-Mailer: Apple Mail (2.3445.104.15) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 22:50:57 -0000 > On 18 Aug 2020, at 23:42, Brian E Carpenter = wrote: > On 19-Aug-20 04:01, Colin Perkins wrote: > ... >=20 >> If I=E2=80=99m wrangling the datatracker correctly: >>=20 >> 1608 subscribers to ietf@ietf.org >> =E2=80=A6932 of whom subscribe to at least one list for an active = working group >> =E2=80=A6676 do not appear to be subscribed to any of the active = working groups >>=20 >> 20264 subscribers to mailing lists for active working groups.=20 >=20 > Interesting. But without further analysis of people who use different > addresses for different lists, and how many of those addresses are > dormant, it's not clear what the definitive conclusions should be. Sure =E2=80=93 and such analysis is possible, but will take time. > At face value, 932/20264 would rather seem to validate my claim that > less than 10% of participants are interested in plenary matters. That=E2=80=99s certainly one interpretation; another might be that less = than 10% of participants can stand the bickering and toxic atmosphere on = the ietf@ mailing list. Getting a clear answer to which is the case = might be difficult.=20 Cheers, Colin= From nobody Tue Aug 18 16:07:13 2020 Return-Path: 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 1CDE23A0F2D for ; Tue, 18 Aug 2020 16:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.85 X-Spam-Level: X-Spam-Status: No, score=-2.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 lbPxJvMU8JoD for ; Tue, 18 Aug 2020 16:07:09 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6943A0F24 for ; Tue, 18 Aug 2020 16:07:09 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QFA0FBAG87W7J@wwwlocal.goatley.com> for gendispatch@ietf.org; Tue, 18 Aug 2020 18:07:09 -0500 (CDT) Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QFA00FE986U8M@trixy.bergandi.net> for gendispatch@ietf.org; Tue, 18 Aug 2020 16:06:33 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Tue, 18 Aug 2020 16:06:33 -0700 Date: Tue, 18 Aug 2020 16:07:05 -0700 From: Dan Harkins In-reply-to: <02A012DC-706E-44F1-8CEB-39F8F6FC40C1@csperkins.org> To: gendispatch@ietf.org Message-id: <6fa121f3-6aa0-7380-3fd2-25cfdf3cd443@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local) References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <256AB2A2-3936-4D72-95D2-12FFBB893326@csperkins.org> <02A012DC-706E-44F1-8CEB-39F8F6FC40C1@csperkins.org> X-PMAS-Software: PreciseMail V3.3 [200817] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 18 Aug 2020 23:07:11 -0000 On 8/18/20 3:50 PM, Colin Perkins wrote: >> On 18 Aug 2020, at 23:42, Brian E Carpenter wrote: >> At face value, 932/20264 would rather seem to validate my claim that >> less than 10% of participants are interested in plenary matters. > That’s certainly one interpretation; another might be that less than 10% of participants can stand the bickering and toxic atmosphere on the ietf@ mailing list. Getting a clear answer to which is the case might be difficult.   Well how many people attend the IETF Plenary at in-person meetings? Maybe 250-300 people? Out of 1100-1200 or so? So let's say 20%? 25%? And figure half of them are reading mail or expressing bad attitude on jabber so then roughly 10% of the attendees of the meeting are interested in the goings on at the plenary.   Dan. From nobody Tue Aug 18 17:06:28 2020 Return-Path: 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 997443A103C for ; Tue, 18 Aug 2020 17:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: 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_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=mnot.net header.b=FU7K9Ryw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pcuJzY5D 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 AXjhG7uw2EER for ; Tue, 18 Aug 2020 17:06:26 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE5F43A1038 for ; Tue, 18 Aug 2020 17:06:25 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 144CAF61; Tue, 18 Aug 2020 20:06:25 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 18 Aug 2020 20:06:25 -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=fm3; bh=R 61yh4bSWiv48L5kCJYzjjTOwsrndW5+Ylfgz/5KR/8=; b=FU7K9RywJQrHfyBQ1 zhrF4FfQlO3LPmNTXDUP3ql7MZpTtYhwFjTJvKj0KCQxQ8v+zfCPbfcyaw652Km3 fiebczOwD/rAFc+4iuIr4K603QxIail2UcvVaAejbsjpIYLHwCNJruAw8b4X2RcZ cf3agyL/HGShCtS/RCUx3Q02TO8ctfa3RXnytkr0n7Lo4gpfV87HzklJp+CkpTHm J4rEEZyapGVw5+lL5+pnmNI2Ob4i+1HX6W7qBMGAU9SFhcG5mDcVqm8hDnABf8sv 1f1mk7isJlCXIar1jFTmBT+y3ZLEJHS/EhJt6O/iSXePff462XY3A9Xb3adQINN3 LRI8Q== 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=fm3; bh=R61yh4bSWiv48L5kCJYzjjTOwsrndW5+Ylfgz/5KR /8=; b=pcuJzY5Dr91hHLsweWjCQ9D2aLiJL50W5gxgy6qi8ywxB34gNbfKGT5Jc URNi/MzKVvusyOFNyMjYh53no0MTRFCUWi64adjJBDw4z0kTBCdaFsU2Op2LGVTA fs0fDrvOLwMiMonIbS5TuADe7OrDu1kRE5h0ARUxbHWAV57Xt7YmDUfdjA93hPIV mIOZ/qe6Nl/6eHU9DV5TJFLE41+tYNvy6cd+JPeqPIbCSWL3O/WM7/5AxbMSUqGe LKZbpEAhNXjQYt7qLh9Nq6XgbmCrbkc08ynKXEUgGA7XDDlfc1ZoU/R3UqeZ4rNt aeDLbuNmJHCVjOYkRV2dvvPJDXAGw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtjedgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeetleekgeduvefhvdevudeghfetleevleelhfefvdekheduteetgfehjeelleet heenucffohhmrghinhepthhimhgvrghnuggurghtvgdrtghomhdpvghpihhsthgvmhgvrd hnvghtpdhivghtfhdrohhrghdpmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudeh kedrvdehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: 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 89071306005F; Tue, 18 Aug 2020 20:06:22 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <7F182A25-424B-40FB-9414-91410A8524CF@episteme.net> Date: Wed, 19 Aug 2020 10:06:20 +1000 Cc: gendispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <0E6B27FC-FF54-42DC-A13A-5F94C36F67C2@mnot.net> References: <7F182A25-424B-40FB-9414-91410A8524CF@episteme.net> To: Pete Resnick X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Gendispatch] Results of Doodle poll X-BeenThere: gendispatch@ietf.org 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: Wed, 19 Aug 2020 00:06:28 -0000 For those in other timezones: = https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DGENDISPATCH+In= terim+I&iso=3D20200901T20&p1=3D1440&ah=3D2 = https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DGENDISPATCH+In= terim+II&iso=3D20200907T11&p1=3D1440&ah=3D2 Cheers, > On 19 Aug 2020, at 12:30 am, Pete Resnick = wrote: >=20 > Francesca and I looked at the results of the Doodle, and here are the = proposed dates and times (in UTC) for two interim meetings we plan to = hold: >=20 > Tuesday, 1 September at 20:00-22:00 > Monday, 7 September at 11:00-13:00 >=20 > That seemed to us to get everyone able to attend at least one meeting, = and enough people who can make both to carry over some context. Yes, we = scheduled 2 hours per meeting; we don't have to use all of it. >=20 > As the saying goes: Speak now or forever hold your peace. >=20 > Francesca will be preparing a message with an agenda and a description = of goals soon. >=20 > pr > --=20 > Pete Resnick https://www.episteme.net/ > All connections to the world are tenuous at best >=20 > --=20 > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch -- Mark Nottingham https://www.mnot.net/ From nobody Tue Aug 18 21:33:20 2020 Return-Path: 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 8DB293A1170; Tue, 18 Aug 2020 21:33:18 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=gmail.com 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 SJtveGqgJ3Vn; Tue, 18 Aug 2020 21:33:17 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F0C43A116F; Tue, 18 Aug 2020 21:33:17 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id v6so23336666iow.11; Tue, 18 Aug 2020 21:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PZCYbWGKc1I3+busb9Osdc2Vk+fjSq2ZaE+BHEglbtk=; b=NhRXamUh5QDSBZSeJ2DtiH3KzQ4RCP+FFg39dFpdl85jIHCCML2pJDsgDxR1XS+YP1 lgZ8wC2DpMzSyrUsY9toJyvkowZcK/h3SrvKpZ/NIabBnAYK8/MkBzbDHNfAhlr9cwtt kZ6NbxAZXKpZFRvuW+9QUMjZDiR4QiuAsQ2zOCkv//0sHf0tOH/AJsUxDiirDCXG1bgM O+XRoqX49L9Hv/KUebGVPBSgHjNUg85G/EYmljFwKpJcyICWSqEGXQRN0yMKepwbZIt2 ErKJ3HtF4vN0dxSKLNfO/83NsNXobBav4hB4UMmhferqwmhOB332kFiZr15sDOTz/QM+ exlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PZCYbWGKc1I3+busb9Osdc2Vk+fjSq2ZaE+BHEglbtk=; b=gaMO1wyYH2IfKPe/nzCLBNTJ1DLr1D5i7nmYHJzwvToJmEprBOyovezx8l4bcyQR7v Vbss0MQj6SrzmvIABcKtgpxPRvzNoyOY2OCXpIkCLqJLXnahQ1X7wuAVvMEkccIxd5Ax ZHKpRyQEJJuyytC9tLwdB1dlPUNS6i7UXRuV7+b7gKZQfZ2fltERsMQgHlXoz64ltkWH di1vz4eSX6LKWPQ7ck02h9+DVFt4w/rYskYHiZY06vY+65YxFeCr4rXWwYlOdZwv8cJq tmdEXO2ZjJn9WsJWbIhd7RFukydYR8cP/XG9YHzVWXpeJ2TWstHBJlQ/yOWws/QU9IG8 SwGQ== X-Gm-Message-State: AOAM5339mguZorfm9UakkPCYA0XyzGZf3VjcmyqIFSisGmOGL6MCg5vy 5H9ucZXKesQ/Ctwe3yFaVX/KT7/athHb/Dvm2C0= X-Google-Smtp-Source: ABdhPJxeROPCRrYFE8ey4QOUIMcymL79ERihOi323D41Jwvqgx6TPI4hJYXJZl/gHHCUfBbsDsM9Ss/NQuXYTSMkTT8= X-Received: by 2002:a5d:9f0e:: with SMTP id q14mr11401412iot.69.1597811596186; Tue, 18 Aug 2020 21:33:16 -0700 (PDT) MIME-Version: 1.0 References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <256AB2A2-3936-4D72-95D2-12FFBB893326@csperkins.org> <02A012DC-706E-44F1-8CEB-39F8F6FC40C1@csperkins.org> In-Reply-To: <02A012DC-706E-44F1-8CEB-39F8F6FC40C1@csperkins.org> From: Rob Sayre Date: Tue, 18 Aug 2020 21:33:05 -0700 Message-ID: To: Colin Perkins Cc: Brian E Carpenter , gendispatch@ietf.org, Jay Daley Content-Type: multipart/alternative; boundary="0000000000009bd99805ad3380fb" Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Wed, 19 Aug 2020 04:33:19 -0000 --0000000000009bd99805ad3380fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 18, 2020 at 3:51 PM Colin Perkins wrote: > > That=E2=80=99s certainly one interpretation; another might be that less t= han 10% > of participants can stand the bickering and toxic atmosphere on the ietf@ > mailing list. Getting a clear answer to which is the case might be > difficult. > The way this draft suggests demoting the the ietf@ mailing list (perhaps as an experiment) is a great way to test this. thanks, Rob --0000000000009bd99805ad3380fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

That=E2=80=99s certainly one interpretation; another might be that less tha= n 10% of participants can stand the bickering and toxic atmosphere on the i= etf@ mailing list. Getting a clear answer to which is the case might be dif= ficult.

The way this draft suggests de= moting the the ietf@ mailing list (perhaps as an experiment) is a great way= to test this.

thanks,
Rob
--0000000000009bd99805ad3380fb-- From nobody Tue Aug 18 22:35:39 2020 Return-Path: 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 88AEC3A11D1 for ; Tue, 18 Aug 2020 22:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: 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_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=mnot.net header.b=X6dsEIR3; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NTgnOELz 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 9QwcnZVbSfWJ for ; Tue, 18 Aug 2020 22:35:35 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46F6F3A11D0 for ; Tue, 18 Aug 2020 22:35:35 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 77ED0C2B; Wed, 19 Aug 2020 01:35:34 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 19 Aug 2020 01:35:34 -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=fm3; bh=K 4J3F89Wrro+QEkIh+3hdbPaSSOoj/qx7Z//0MP0f/I=; b=X6dsEIR3cSKxA3TS8 O0UWlgb6970kbSpStZghYL9vju/07bq9YWWCcEdiFvFpa6xphQ1JMXrR8w4G0qGp MNLWeNsYDC0xy1vEqVh7/LgRnb7wOHd6rF7cLJznz/jtRXOCM247HL7tGkQ65GAQ IC/0CiPZiELpRjkvDd9n30CPpGkUckSiZgSNjncYiwjlfWm9vbBZANBCtYVwEz52 CkPMBXzwgs12US6NwkPsdx0tRmj6LtwTEEZsDjrz5MQXPKnMEZ86tH6ceFY+U9x2 Z5YYyJgnM09LMp3hT8SqhVkm/PUEYei53r0g6NPuQUpuS/PVo0/f/gY5hrwZ1jIO pNrZA== 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=fm3; bh=K4J3F89Wrro+QEkIh+3hdbPaSSOoj/qx7Z//0MP0f /I=; b=NTgnOELzDCOKgaQdk6KDj73zXtJ/l3qr+6ZAXP0JASFwaJxC3FS1OJYlZ NL0hAXY92/M/QsgT7765dXBpOMPz89xKRdUn2h+gR4IYK/1HCeLZVZRqogZu6HQ9 uEcaDJ2xQsa64I/s5YSQuxDPUg/aXiQ6jHHHxQg3F4LMoilu+4/oJk1BuAys488H c0vl6QsbVQ6+zoFTaasojmRF6eiLiedHmH3QFg4e9wpMBzETkezmiOp0uuJKPYuA wl6HwSHRh5mTRfTGy1moQk9RrkVwgmckgVm0zzARc2lx87ivqA1pMBC1W6YjXcuu /EgbTLDe6tBgQv3tBCvknUfBSYZtw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtjedgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeevffffhfduteevvefhueffieegtdeutdehffeltefffedttdeggeejheeiueet teenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvd ehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvght X-ME-Proxy: 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 91F7A3060067; Wed, 19 Aug 2020 01:35:32 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: <090f2c01-6494-7be3-4b99-280576733f35@huitema.net> Date: Wed, 19 Aug 2020 15:35:30 +1000 Cc: gendispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7B731DC9-5CB6-4D5B-A382-1E3179D39A9F@mnot.net> References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <20200818164957.GA86346@straasha.imrryr.org> <090f2c01-6494-7be3-4b99-280576733f35@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Wed, 19 Aug 2020 05:35:38 -0000 Hi Christian, I'm not going to respond to every message on this thread, as I want to = hear what others think.=20 I think we agree that the question at hand is reconciling the nature of = the discussion with the need for it. My draft is one proposal; there = maybe others, and I'm happy to discuss changing mine. I wrote this one = down because it's pretty clear (at least to me) that imposing rules of = order on this list isn't possible, because many people are unwilling to = change how they use or think about it. If I'm wrong about that, that's = great. Regarding 'Mark's proposal also does away with any notion of an online = general assembly' -- My expectation is that even if the IESG and other = leadership would be told that they don't have to listen to ietf@, they = still would -- provided that the list didn't become mired in endless = acrimonious cycles, as it has of late. De-emphasing the list also = restores some balance between those that use it to amplify their voices = and those who are turned away from such activity. Perhaps that goes too far, and there does need to be an expectation that = leadership will be on the list. If that's the case, it's important to = recognise that this becomes a selector for leadership -- if you can't = 'take it' on the ietf@ list, you're not fit for leadership. That will in = turn reduce the diversity of work and participants in the IETF over = time.=20 Cheers, > On 19 Aug 2020, at 3:32 am, Christian Huitema = wrote: >=20 > I am not entirely convinced by Mark's draft either. My personal = assessment is that we have many problems: >=20 > * The IETF list acts as the offline general assembly, but without any = rules of order. We would not run a meeting of 1000 people without any = such rules, and for example we use mike queues and time limits during = the plenary. The lack of order leads to poor behavior and reduced = utility. >=20 > * The IETF list also acts as the IETF lobby, a place that newcomers = might join in order to sense the pulse of the organization. But we are = conducting a permanent and sometimes very loud general assembly in the = lobby, and that scares visitors away. >=20 > * To expand on the previous point, the tolerance for loud discussions = naturally selects for loud spoken and loudness tolerant individuals, = typically oldtimers. It turns away other types of participants, = contributing to lack of renewal and lack of diversity in the = organization. >=20 > * As Mark points out, the list membership is a fraction of the IETF = participants, which makes it a rather unrepresentative general assembly. = But that may well be a consequence of the other issues. >=20 > Mark's proposal addresses the "rules of order" issue by directing = discussions to the gendispatch WG, and then possibly to specialized WG. = The advantage is that WG chairs can and do impose discussion rules. We = have examples that it works, e.g., moving the RFC-ED discussion from the = IETF list to a specialized group. But Mark's proposal also does away = with any notion of an online general assembly -- the IETF list is left = to its own devices, some kind of playground for people who like loud = debates, and the IESG is told that it just does not have to listen. That = seems sub-optimal, because feedback is indeed useful. >=20 > If I am right -- :-) -- the main missing component is some kind of = "rules of order" for the IETF list, similar to the mike lines and time = limits that we have in working groups or in the physical plenary. This = requires some authority to enforce the rules, an authority that should = be separate from the IAB/IESG leadership if we want an avenue of = feedback for that leadership. >=20 > We may also consider not washing our dirty laundry in the front lobby, = i.e., separating the "social discussion" and "plenary" functions. >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Wed Aug 19 06:10:52 2020 Return-Path: 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 ECBB33A099C for ; Wed, 19 Aug 2020 06:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 36CsQn_d8ob2 for ; Wed, 19 Aug 2020 06:10:48 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A35CE3A096C for ; Wed, 19 Aug 2020 06:10:48 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E0AC25C0176 for ; Wed, 19 Aug 2020 09:10:47 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 19 Aug 2020 09:10:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=L02rseOsMfFj6rX7OvtdrvsRwIVs9w09qyoWChzvW n8=; b=hWOwbdZu1Hp2Hu+7LCBUiUL66nSBjL4i083GYCsnHRn/qz4C3d4JacEe7 ZSXFANEJRY1kZEEScoFCq7hGBJLBLILyp/8J0E0Iaz8Cx6HZJ8sXBgd/h6Ab8RMx Z5OfTPftzvFxiQlfSyjBr54OfXkM/iqjwF//3washfN7fkUapC0cRcREd8G0yhfG lpcO15tqW5FpNqpkcSf4OsTudGMfEl7pXdW4GqzK3CMhoYax2jZE/Wn+QM188PMn EWvQWOfGvpnSuRFOn6h9WyZP9ewYoiXGwg1b9lb3k+7Ca+u80FEU1zedCW7js1V/ IFxOB3NGJDhgbs8JiHNPHk3Tj/hQw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtkedggeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeehhfeutdehfe fgfefghfekhefguefgieduueegjeekfeelleeuieffteefueduueenucfkphepuddtkedr vddvuddrudektddrudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 611A230600A3 for ; Wed, 19 Aug 2020 09:10:47 -0400 (EDT) To: gendispatch@ietf.org References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> From: Keith Moore Message-ID: <48f667c1-d25d-2983-72b5-336a6f800294@network-heretics.com> Date: Wed, 19 Aug 2020 09:10:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Wed, 19 Aug 2020 13:10:51 -0000 On 8/18/20 10:42 AM, Kyle Rose wrote: > Can we stop using the word "toxic" in our analysis of the problem? One > person's toxic thread is another person's debate on a serious, > material complaint. That sometimes the discussions devolve into name > calling by some shouldn't be used as a justification for downplaying > the seriousness of the underlying issues. Yes, and would people try to be more descriptive/specific as to what they mean by "toxic"? I hope people don't use the word "toxic" to mean merely "it makes me uncomfortable".   But I can't tell what they mean. Reading the ietf list sometimes makes me uncomfortable but at least for me it's usually in _what_ they are saying as opposed to _how_. (And then I have to remind myself that I need to accept the reality of different points-of-view, to accept that there really are people who want to destroy what I believe is essential about IETF, and admit they may think they're doing a Good Thing even though I disagree, and they may have valid points even if I strongly oppose their proposed remedies.   None of which is fun, but it's necessarily part of the hard work of trying to find common ground that can lead to rough consensus.) Keith From nobody Wed Aug 19 08:41:19 2020 Return-Path: X-Original-To: gendispatch@ietf.org Delivered-To: gendispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18AFC3A0C8B; Wed, 19 Aug 2020 08:41:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: gendispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159785167583.11111.2959126579778884856@ietfa.amsl.com> Date: Wed, 19 Aug 2020 08:41:17 -0700 Archived-At: Subject: [Gendispatch] General Area Dispatch (gendispatch) WG Virtual Meeting: 2020-09-01 X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 15:41:17 -0000 The General Area Dispatch (gendispatch) WG will hold a virtual interim meeting on 2020-09-01 from 20:00 to 22:00 UTC. Agenda: Discussion of document terminology. Detailed agenda will be provided soon. Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mc2aa8693edeab1faf17e92954c44f316 From nobody Wed Aug 19 08:43:43 2020 Return-Path: X-Original-To: gendispatch@ietf.org Delivered-To: gendispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9A33A0B2F; Wed, 19 Aug 2020 08:43:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: gendispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159785181749.26882.17633376844548277911@ietfa.amsl.com> Date: Wed, 19 Aug 2020 08:43:37 -0700 Archived-At: Subject: [Gendispatch] General Area Dispatch (gendispatch) WG Virtual Meeting: 2020-09-07 X-BeenThere: gendispatch@ietf.org X-Mailman-Version: 2.1.29 List-Id: General Area Dispatch List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Aug 2020 15:43:38 -0000 The General Area Dispatch (gendispatch) WG will hold a virtual interim meeting on 2020-09-07 from 11:00 to 13:00 UTC. Agenda: Discussion of document terminology. Detailed agenda will be provided soon. Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mf75d83e0c6c2d55506cc51db56334b42 From nobody Wed Aug 19 21:06:10 2020 Return-Path: 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 131DF3A10DF for ; Wed, 19 Aug 2020 21:06:09 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=gmail.com 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 tBoXZ-7ATRaL for ; Wed, 19 Aug 2020 21:06:06 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 609E23A10DC for ; Wed, 19 Aug 2020 21:06:06 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id v6so942592iow.11 for ; Wed, 19 Aug 2020 21:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bbufED+gD9VYXlP1xxLUjzxMoBJ9Bgu9pMTGiJyhyXU=; b=GJnRDD7Sdu3TtZM1jz/mwIpuo3eY5E2HjA8XcWGW6ZyYgKWcKl2xj9xI27W+gLN+EX jhzHmUaDURJpjoqq0c3xFL+zhxT4BC0GXuCwVyNpehAM7QhjUn1MlcBE6w72xKhMgsoQ NO51F4tWSdlVhrqr/6SqRcYjOQeddRN4GdveA0hYM+5K0eVZkef/YXPQbNWPNlrGHfDd +9YbeUkJsac+rz7TAWhVhRV+FghKuaGNSEnLYJ75sfhPZoOu/AmGJOXlpXohHFAjldMO 9DKtuI3WJjcgUu534/kfW92Kp0P4r4b8njmdDNARCA8Vt1X3SZxcCPZz+HNkmCwhWZ48 NCcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bbufED+gD9VYXlP1xxLUjzxMoBJ9Bgu9pMTGiJyhyXU=; b=rEj9KhykbRoXk3Nan1IwF5aCX/yMyty2+usn5azJCJyBGcUMwAgAjmzUXYEojB5SGS 5/vchf5X0rR2qkba2/s2sSGNNpGGia6TaeT9805lLwWvDmqxGQIx6gc2S6BHtfRyUMiC t5dE2ji0v3bzeeqziCuWiLYVj46ZdqgJYHVU2xoDYuZz+nISx1OPKG0RkVWA7ZIoFXwY CDNkko1OUYey7ZNTzjM7lsovv7PDj1Mea2QEbtGLoGJvc3i6Q8UWzy4b+dcmeeuwxLZI L3o9xSujRZ06FFGle9V50zFcK8w4FhWvaszWHHcnVjAq89PZL00fMGUiTcy72qdtf1AH y9fA== X-Gm-Message-State: AOAM533lNsTmcu/bTK0yFnM/CTaMxwgH6YiTUEzlDH01g6/vRyG0yAUd 3V0ZYNm4WrWtxnV4VLno4OkEK+6HOrNDEYseuwbC1VguIzXoAA== X-Google-Smtp-Source: ABdhPJyEJFmuX51V5Mop6BV7HCktA/dhpRMRBoX1iyMrhaHrPAYRR91OUnH5y6dzDeeGqr0TKhMa7NV6hD6LLcgULNs= X-Received: by 2002:a05:6602:1495:: with SMTP id a21mr1060997iow.46.1597896365209; Wed, 19 Aug 2020 21:06:05 -0700 (PDT) MIME-Version: 1.0 References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> <48f667c1-d25d-2983-72b5-336a6f800294@network-heretics.com> In-Reply-To: <48f667c1-d25d-2983-72b5-336a6f800294@network-heretics.com> From: Rob Sayre Date: Wed, 19 Aug 2020 21:05:53 -0700 Message-ID: To: Keith Moore Cc: gendispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000003c7e3505ad473d3f" Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 20 Aug 2020 04:06:09 -0000 --0000000000003c7e3505ad473d3f Content-Type: text/plain; charset="UTF-8" On Wed, Aug 19, 2020 at 6:10 AM Keith Moore wrote: > On 8/18/20 10:42 AM, Kyle Rose wrote: > > > Can we stop using the word "toxic" in our analysis of the problem? One > > person's toxic thread is another person's debate on a serious, > > material complaint. That sometimes the discussions devolve into name > > calling by some shouldn't be used as a justification for downplaying > > the seriousness of the underlying issues. > > Yes, and would people try to be more descriptive/specific as to what > they mean by "toxic"? > It seems like the ietf@ list has been damaged by "sealioning". https://www.urbandictionary.com/define.php?term=Sealioning I can't tell exactly which messages fall under that definition, but I am pretty sure that some of them do. This proposal seems to remove habitat for the described behavior, and I can't see a downside. thanks, Rob --0000000000003c7e3505ad473d3f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 19, 2020 at 6:10 AM Keith Moo= re <moore@network-heretics= .com> wrote:
On 8/18/20 10:42 AM, Kyle Rose wrote:

> Can we stop using the word "toxic" in our analysis of the pr= oblem? One
> person's toxic thread is another person's debate on a serious,=
> material complaint. That sometimes the discussions devolve into name <= br> > calling by some shouldn't be used as a justification for downplayi= ng
> the seriousness of the underlying issues.

Yes, and would people try to be more descriptive/specific as to what
they mean by "toxic"?

It seem= s like the ietf@ list has been damaged by "sealioning".

https://www.urbandictionary.com/define.php?term=3DSealioning

I can&#= 39;t tell exactly which messages fall under that definition, but I am prett= y sure that some of them do.

This proposal seems to remove habitat for the descri= bed behavior, and I can't see a downside.

thanks,
Rob

--0000000000003c7e3505ad473d3f-- From nobody Wed Aug 19 21:11:01 2020 Return-Path: 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 DCE3C3A1193 for ; Wed, 19 Aug 2020 21:10:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 Vfi3NOOAEcMR for ; Wed, 19 Aug 2020 21:10:58 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA87F3A118F for ; Wed, 19 Aug 2020 21:10:57 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id F1C735C0183 for ; Thu, 20 Aug 2020 00:10:56 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 20 Aug 2020 00:10:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=fm3; bh=+GZASb mJy6ISHaRVOyCpd3yFf2IBmlICVqYAX3mEc6M=; b=JoNFA0yksQsswYvkmIt3EU iaOHLGuLsxGLIL4NVXVNc66DnrlY1cHfUu0lBJQErydjcRgqrIOkEJKaf6825EXi 7cutQgXgJqK9TWc3wMb38ZHDHEj3EYbdfr+iTK13359Zy2oNTryQVevw9pAGiZBA CW0U7vz/1PyO6XwDG16sCrjWeqgsZrY1oo1iTNdsgNG/HwgmMEMkt/HSUNXlhQ6l XOhwUiE3WLBmuA1nXq5BtXrFTKaPzvU2WuFeOELUvkseStofb0wLjvZNBsukK7Uc VeoYebOGbOfxFD7TwsM511aZW+kVXGsvUqpNBmzcl2VFvOSIeKoo0DsvU/gmtB2Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtledgieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepueekkedtgfetfe evjedtgedtjeettddtuddtteefuefgkeekkedufeekveeggfffnecuffhomhgrihhnpehu rhgsrghnughitghtihhonhgrrhihrdgtohhmnecukfhppedutdekrddvvddurddukedtrd duheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm ohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id B1E4730600B9 for ; Thu, 20 Aug 2020 00:10:55 -0400 (EDT) To: gendispatch@ietf.org References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> <48f667c1-d25d-2983-72b5-336a6f800294@network-heretics.com> From: Keith Moore Message-ID: <25b91252-14a1-2267-06eb-293779df0be6@network-heretics.com> Date: Thu, 20 Aug 2020 00:10:54 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------63E64B464D84F3DC55B1F926" Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 20 Aug 2020 04:11:00 -0000 This is a multi-part message in MIME format. --------------63E64B464D84F3DC55B1F926 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 8/20/20 12:05 AM, Rob Sayre wrote: > > It seems like the ietf@ list has been damaged by "sealioning". > > https://www.urbandictionary.com/define.php?term=Sealioning > > I can't tell exactly which messages fall under that definition, but I > am pretty sure that some of them do. I generally find it unhelpful in the extreme to presume bad intent in the absence of a preponderance of evidence. Keith --------------63E64B464D84F3DC55B1F926 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/20/20 12:05 AM, Rob Sayre wrote:


It seems like the ietf@ list has been damaged by "sealioning".

https://www.urbandictionary.com/define.php?term=Sealioning

I can't tell exactly which messages fall under that definition, but I am pretty sure that some of them do.

I generally find it unhelpful in the extreme to presume bad intent in the absence of a preponderance of evidence.  

Keith


--------------63E64B464D84F3DC55B1F926-- From nobody Wed Aug 19 21:25:29 2020 Return-Path: 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 704A83A08F5 for ; Wed, 19 Aug 2020 21:25:28 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=gmail.com 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 8zlint8PBzjj for ; Wed, 19 Aug 2020 21:25:27 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20B853A08ED for ; Wed, 19 Aug 2020 21:25:27 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id q14so645987ilj.8 for ; Wed, 19 Aug 2020 21:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nXfK5APb1HV6Zlt1ch4qG+b9UQZ0mjfbrsf3cRGe4b0=; b=Le/wvVtrTUYGICzOquypRtTLcszAHKL8h8uzudrHnQA4mvCunDsVEKM5AZsyk0qz7q OWe737nxiaInNDhxrR4spMNAXHxMm2VElBa3hztz4N4kyblcuj2UeGaq1rJhjjuKyfWL M8tGbJndd7cC5W4NktWB0ZDUam0IozPoKHjh9lw/k7/d73dtko2OxL+QW+xBg4DS2L6C G22BfDFM0Pa7zjw5d2QFgWZTcADcJr8IClWHw0wtr+d+yVMdMTLPBbe5Gxp+w2YrShVg z4jMg5P0+AeYj/UXuqnYs6xjPvFs/7srXTux82MH9LtoHYbi1XtYVCkXJ1hN3zS10YXG vBEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nXfK5APb1HV6Zlt1ch4qG+b9UQZ0mjfbrsf3cRGe4b0=; b=UDHQSF2ObswCROSHI+PAbQgGqzSWiBmeHmB4exk0Wb/CQKOv+EImEE141NVOtHfdve dGM7lffp5JSbkzwfUUvm3PqbeldKJWQTkuePzpSRqPia1GWuNEMvGCVNJDE07EDCqWp2 fAHcRItdYSMdnEbD7kbWgNXQW695SV36SNo6NxZyt2rsV0Wqp1KjJhOBBmOspeG+UBmC +PtdWnH4IDogZYT6qkDeylEaQn5N4yqqv5pi6K6i1PgWeZcUfMFgtcFN3IAN7Msg1Dzw n3GqCoRpHPufoNzcBrBH4SvY5mvAFp3uwaqX6/kK8+zCVd7/82W0QYcl9BOkkjTXdNvf riPw== X-Gm-Message-State: AOAM530RNazVV/j9aBzZJBoJYwg2l1cRGWgUgzNITFm9jP1DD/tzX0ci sxWa1tR2zLU+ARZO3zi7zatfKqwT2yBznJwbOyJd5/yUtd8= X-Google-Smtp-Source: ABdhPJzOse/l8axz1jz8zh1UELTT78J5sNlhl0y+FqyehIgwYftSdJ5TMEDXMnwEBQhAo1+zc0Iy+nm5vjZtC1ScnCE= X-Received: by 2002:a05:6e02:1212:: with SMTP id a18mr1190322ilq.73.1597897526341; Wed, 19 Aug 2020 21:25:26 -0700 (PDT) MIME-Version: 1.0 References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> <48f667c1-d25d-2983-72b5-336a6f800294@network-heretics.com> <25b91252-14a1-2267-06eb-293779df0be6@network-heretics.com> In-Reply-To: <25b91252-14a1-2267-06eb-293779df0be6@network-heretics.com> From: Rob Sayre Date: Wed, 19 Aug 2020 21:25:15 -0700 Message-ID: To: Keith Moore Cc: gendispatch@ietf.org Content-Type: multipart/alternative; boundary="00000000000071f65205ad478267" Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 20 Aug 2020 04:25:28 -0000 --00000000000071f65205ad478267 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 19, 2020 at 9:11 PM Keith Moore wrote: > On 8/20/20 12:05 AM, Rob Sayre wrote: > > > It seems like the ietf@ list has been damaged by "sealioning". > > https://www.urbandictionary.com/define.php?term=Sealioning > > I can't tell exactly which messages fall under that definition, but I am > pretty sure that some of them do. > > > I generally find it unhelpful in the extreme to presume bad intent in the > absence of a preponderance of evidence. > That is pretty much the definition of the trust that sealioning takes advantage of. I favor removing the habitat. I don't want to guess at anyone's motivations, and I don't see a lot of productive input coming from the ietf@ list that couldn't be delivered elsewhere. thanks, Rob --00000000000071f65205ad478267 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 19, 2020 at 9:11 PM Keith Moo= re <moore@network-heretics= .com> wrote:
=20 =20 =20

On 8/20/20 12:05 AM, Rob Sayre wrote:


It seems like the ietf@ list has been damaged by "sealioning".

https://www.urbandictionary.com/define.php?term= =3DSealioning

I can't tell exactly which messages fall under that definition, but I am pretty sure that some of them do.

I generally find it unhelpful in the extreme to presume bad intent in the absence of a preponderance of evidence.=C2=A0

=

That is pretty much the definition of the = trust that sealioning takes advantage of.

I favor = removing the habitat. I don't want to guess at anyone's motivations= , and I don't see a lot of productive input coming from the ietf@ list = that=C2=A0couldn't be delivered elsewhere.

tha= nks,
Rob

--00000000000071f65205ad478267-- From nobody Wed Aug 19 21:33:28 2020 Return-Path: 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 5C3913A0B53 for ; Wed, 19 Aug 2020 21:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 yckJ_s09CzUf for ; Wed, 19 Aug 2020 21:33:25 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE16B3A0B4C for ; Wed, 19 Aug 2020 21:33:25 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id BD5879B9; Thu, 20 Aug 2020 00:33:22 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 20 Aug 2020 00:33:22 -0400 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=fm3; bh=eF8Vgn HW4qoGlTOnTtp0DyDQeJGAZiTVBP376hLNfIo=; b=Yw93KWAupgdLp3rM9Skd/e omyQZKQX4aqkrTRsevLQWAW4xS110Tm9tDZjJQEaVFnUgTxpB4I8JZU008+RTHkf 0/tZCH8aVG4SJzLVHisn8hQCeDoo3tJe12YSqlYGpRB1fUlfJKYuTiAngrQs9alI 1GJ1MuYTxcfzvf5okdvND/DJ+5edQUDady//GiZkShrWgsSHscvlD40Wv+DfL4Ep hygN03xMBHFfmvumI0/kceXR/eQ/ZrEPTicSWpJ333OtXuuGgBPNexQqYXF6Dttt VLrS0j7WB/zBVFxpvYil0IoqnxoEBHQfPoHeVHXKEHVYggLwbFplUhLlq/jkJWCQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtledgieejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtsegrtderredtfeejnecuhfhrohhmpefmvghithhh ucfoohhorhgvuceomhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhmqe enucggtffrrghtthgvrhhnpeeukeektdfgteefveejtdegtdejtedttddutdetfeeugfek keekudefkeevgefgffenucffohhmrghinhepuhhrsggrnhguihgtthhiohhnrghrhidrtg homhenucfkphepuddtkedrvddvuddrudektddrudehnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrh gvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id AB30430600B1; Thu, 20 Aug 2020 00:33:21 -0400 (EDT) To: Rob Sayre Cc: gendispatch@ietf.org References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> <48f667c1-d25d-2983-72b5-336a6f800294@network-heretics.com> <25b91252-14a1-2267-06eb-293779df0be6@network-heretics.com> From: Keith Moore Message-ID: <0d8c135d-96d9-2cdc-9737-b59d516209ea@network-heretics.com> Date: Thu, 20 Aug 2020 00:33:20 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FB5A2493B77443FFB07D0991" Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 20 Aug 2020 04:33:27 -0000 This is a multi-part message in MIME format. --------------FB5A2493B77443FFB07D0991 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit >> >> It seems like the ietf@ list has been damaged by "sealioning". >> >> https://www.urbandictionary.com/define.php?term=Sealioning >> >> I can't tell exactly which messages fall under that definition, >> but I am pretty sure that some of them do. > > I generally find it unhelpful in the extreme to presume bad intent > in the absence of a preponderance of evidence. > > > That is pretty much the definition of the trust that sealioning takes > advantage of. It's also often the only way to help build consensus.  If you assume malicious intent any time someone has a position that's different than yours, you'll never be able to see merit in their positions, and you're unlikely to be able to contribute to any kind of win-win or compromise. > > I favor removing the habitat. I don't want to guess at anyone's > motivations, and I don't see a lot of productive input coming from the > ietf@ list that couldn't be delivered elsewhere. I emphatically disagree with your characterization.   Just because someone defins a term for an unhelpful tactic, is no reason to presume that it must be defeated at all costs. The "habitat" is essential to the continued functioning of IETF, in particular the community's ability to keep the "leadership" from going off the rails. That's not to say that it's not worth considering some changes, but the named proposal is IMO unacceptable. Keith --------------FB5A2493B77443FFB07D0991 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

It seems like the ietf@ list has been damaged by "sealioning".

https://www.urbandictionary.com/define.php?term=Sealioning

I can't tell exactly which messages fall under that definition, but I am pretty sure that some of them do.

I generally find it unhelpful in the extreme to presume bad intent in the absence of a preponderance of evidence. 


That is pretty much the definition of the trust that sealioning takes advantage of.

It's also often the only way to help build consensus.  If you assume malicious intent any time someone has a position that's different than yours, you'll never be able to see merit in their positions, and you're unlikely to be able to contribute to any kind of win-win or compromise.


I favor removing the habitat. I don't want to guess at anyone's motivations, and I don't see a lot of productive input coming from the ietf@ list that couldn't be delivered elsewhere.

I emphatically disagree with your characterization.   Just because someone defins a term for an unhelpful tactic, is no reason to presume that it must be defeated at all costs.

The "habitat" is essential to the continued functioning of IETF, in particular the community's ability to keep the "leadership" from going off the rails. 

That's not to say that it's not worth considering some changes, but the named proposal is IMO unacceptable.

Keith


--------------FB5A2493B77443FFB07D0991-- From nobody Wed Aug 19 21:33:32 2020 Return-Path: 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 028513A0B67 for ; Wed, 19 Aug 2020 21:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 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, NICE_REPLY_A=-0.949, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 m65edYr3m7Yw for ; Wed, 19 Aug 2020 21:33:28 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E7153A0B53 for ; Wed, 19 Aug 2020 21:33:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BXBbr0V3tz6GFQW; Wed, 19 Aug 2020 21:33:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1597898008; bh=K7yS3jl4VZk6LQtlYVBt/6FkfI+fnzT3UUjkwlguLbM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=NnwHTAT9zjjgRbMd+eepGggYN46+2lN5A+buQceaIwc2g0aI57NrRnGsKbBRJzWlK nTLYmsKcPxwgEMrc9QfB1KiH6nVh9/DvsZerYeQUUw/PBtskSrO7FZMiK5oyu0NXwP c3T+8UC2wly9XKeIIuDjHseFallPmi4hkRqLE6+E= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4BXBbq3zj7z6GD5V; Wed, 19 Aug 2020 21:33:27 -0700 (PDT) To: Rob Sayre Cc: gendispatch@ietf.org References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> <48f667c1-d25d-2983-72b5-336a6f800294@network-heretics.com> <25b91252-14a1-2267-06eb-293779df0be6@network-heretics.com> From: "Joel M. Halpern" Message-ID: <7256eac5-d828-7f18-2337-230f299062f9@joelhalpern.com> Date: Thu, 20 Aug 2020 00:33:26 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 20 Aug 2020 04:33:31 -0000 This seems a very bad argument for removing the IETF list. The argument does not cite any specific messages. And seems, although I could be mistaken, to rely on inferring the interpretation of the sender of whatever unspecified messages are being considered. That is a very different claim than the one Mark makes in his email. Which is itself being debated as to the scope and seriousness of the problem. Removing lists has consequences / costs. Yours, Joel On 8/20/2020 12:25 AM, Rob Sayre wrote: > On Wed, Aug 19, 2020 at 9:11 PM Keith Moore > wrote: > > On 8/20/20 12:05 AM, Rob Sayre wrote: > >> >> It seems like the ietf@ list has been damaged by "sealioning". >> >> https://www.urbandictionary.com/define.php?term=Sealioning >> >> I can't tell exactly which messages fall under that definition, >> but I am pretty sure that some of them do. > > I generally find it unhelpful in the extreme to presume bad intent > in the absence of a preponderance of evidence. > > > That is pretty much the definition of the trust that sealioning takes > advantage of. > > I favor removing the habitat. I don't want to guess at anyone's > motivations, and I don't see a lot of productive input coming from the > ietf@ list that couldn't be delivered elsewhere. > > thanks, > Rob > > From nobody Wed Aug 19 21:36:11 2020 Return-Path: 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 F24E43A0B64 for ; Wed, 19 Aug 2020 21:36:08 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=gmail.com 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 mhY3ew-J3Vbl for ; Wed, 19 Aug 2020 21:36:07 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0BF33A0B53 for ; Wed, 19 Aug 2020 21:36:07 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id t4so695777iln.1 for ; Wed, 19 Aug 2020 21:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xAU76tJn3hD3kGXZ75v4LduCxld9nMf6ho1i8c4vCd0=; b=AnGTtZ1xAyU18sx229vH1rC730UoZsK54VbAyVbD8tg2wKubp0J3+T2aqW/89DJNf4 ocYmsJ341pkMOnSI6Ya/cKUEsJi/5RR9ioPLcQiUtuotuIaK+8r9Nzh1RrGZa2YEb18k eV7Ymfr/ptngfQ/gXDiXQh4dB5x6vkw4OP1TloNt3HwfeRr6icaES3BsdWoOJ77GsysG kZlQ/Rcm0bcn/EdcrTNVBJb0THF/+HSPduCndEef5P3Ah1v+ve6IueOOOuMyI7wbbopj jYt6Ec6qD9kGa7gvoXpl8/WATAHdHwGkJQW2DCKH99XKeehqGDvhGe7ObDPrhZWwuruU PGvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xAU76tJn3hD3kGXZ75v4LduCxld9nMf6ho1i8c4vCd0=; b=FvWN+9OVt7U0WX84/+7A0XpwTxm1HqCeAhteoY9nBaDz0uWSZ1zof6eHAoh6c739/a blZ54eADlDQgq6Iv6mCZzUkR5pyfw+jGnNO2xvEy2FhPKDyKk7OSFLij8JcVQN4sRoop Wrrr39XEtnuha0izWwSyLwQCuSwYwXLi01rFF8a2MDQkWLYWaaAHyXv6FIsM0zZX1sa0 6Evv9kgrrJ4ePPHlOtfU+N78Zt5p736kIwtMUxgNGaZfD84HNulUg/kIRm3m1G/3KSwV +C96lDp8qZWCqeObTDfh5uRcI4SYlfpiq3WihQQvTbbr30SMyvkSq2fbW6PtCpSgORbT 85Aw== X-Gm-Message-State: AOAM5309KN8N/MHxFVLBDv2ZgeM/bT/rs23ihfVX/qhlEw1o5yo+F3cs dJasaNt6t0fWEgj1YsXHZfhr2tixUZp1bbjsKE/IZ+hE86M= X-Google-Smtp-Source: ABdhPJzS2kFUDWpkkk+gsks3qNXEOO0e8yVP/w3FEAkT9fyxoT+Y6RA+2PMvEeiQoEswW3drgU9UB87cxbgXob6GZPM= X-Received: by 2002:a92:c904:: with SMTP id t4mr1175636ilp.257.1597898166852; Wed, 19 Aug 2020 21:36:06 -0700 (PDT) MIME-Version: 1.0 References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> <48f667c1-d25d-2983-72b5-336a6f800294@network-heretics.com> <25b91252-14a1-2267-06eb-293779df0be6@network-heretics.com> <7256eac5-d828-7f18-2337-230f299062f9@joelhalpern.com> In-Reply-To: <7256eac5-d828-7f18-2337-230f299062f9@joelhalpern.com> From: Rob Sayre Date: Wed, 19 Aug 2020 21:35:55 -0700 Message-ID: To: "Joel M. Halpern" Cc: gendispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000009f5f9705ad47a8d0" Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 20 Aug 2020 04:36:09 -0000 --0000000000009f5f9705ad47a8d0 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 19, 2020 at 9:33 PM Joel M. Halpern wrote: > This seems a very bad argument for removing the IETF list. > ... Removing lists has consequences / costs. > I believe the proposal does not remove the list. Did I misread? I think it does change the role of the ietf@ list. thanks, Rob --0000000000009f5f9705ad47a8d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 19, 2020 at 9:33 PM Joel M. H= alpern <jmh@joelhalpern.com&g= t; wrote:
This seems a very bad argument for removing the IETF l= ist.

...=C2=A0

Removing lists has consequences / costs.

I believe the proposal does not remove the list. Did I misread?

I think it does change the role of the ietf@ list.

thanks,
Rob
=C2=A0
--0000000000009f5f9705ad47a8d0-- From nobody Wed Aug 19 23:42:10 2020 Return-Path: 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 EC9E73A088A for ; Wed, 19 Aug 2020 23:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Q1KySoNTwack for ; Wed, 19 Aug 2020 23:42:07 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E773A0884 for ; Wed, 19 Aug 2020 23:42:07 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QFC0FBO7NY77J@wwwlocal.goatley.com> for gendispatch@ietf.org; Thu, 20 Aug 2020 01:42:07 -0500 (CDT) Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QFC004B4NX0TO@trixy.bergandi.net> for gendispatch@ietf.org; Wed, 19 Aug 2020 23:41:24 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Wed, 19 Aug 2020 23:41:24 -0700 Date: Wed, 19 Aug 2020 23:42:04 -0700 From: Dan Harkins In-reply-to: To: Rob Sayre Cc: gendispatch@ietf.org Message-id: <7a43b7dc-9703-ad35-5a22-4155646c79f7@lounge.org> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_nmmAiLYlXvKdtc1oj+kwLA)" Content-language: en-US User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local) References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> <48f667c1-d25d-2983-72b5-336a6f800294@network-heretics.com> X-PMAS-Software: PreciseMail V3.3 [200819a] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 20 Aug 2020 06:42:09 -0000 This is a multi-part message in MIME format. --Boundary_(ID_nmmAiLYlXvKdtc1oj+kwLA) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 8BIT On 8/19/20 9:05 PM, Rob Sayre wrote: > On Wed, Aug 19, 2020 at 6:10 AM Keith Moore > > wrote: > > On 8/18/20 10:42 AM, Kyle Rose wrote: > > > Can we stop using the word "toxic" in our analysis of the > problem? One > > person's toxic thread is another person's debate on a serious, > > material complaint. That sometimes the discussions devolve into > name > > calling by some shouldn't be used as a justification for > downplaying > > the seriousness of the underlying issues. > > Yes, and would people try to be more descriptive/specific as to what > they mean by "toxic"? > > > It seems like the ietf@ list has been damaged by "sealioning". > > https://www.urbandictionary.com/define.php?term=Sealioning   Yea, Richard Barnes already made that accusation [1].   Thing is, the definition claims that sealioning means:     "You disingenuously frame your conversation as a sincere request     to be enlightened, placing the burden of educating you entirely     on the other party. If your bait is successful, the other party     may engage, painstakingly laying out their logic and evidence in     the false hope of helping someone learn." and that's the thing. "The other party" (that being YOU! since you're accusing others of sealioning) never engages in any laying out of their logic and evidence here. It's just accusations of bullying [2] and toxicity [3]. When asked for exactly what makes words "exclusionary" and who is excluded by them and why, the response is that we haven't agreed yet that words can be "exclusionary" so the actual reasoning on why one would make such an assertion-- the "logic and evidence", an actual answer-- need not be given [4].   Merely accusing others of bad faith is not painstakingly laying out of logic and evidence. > I can't tell exactly which messages fall under that definition, but I > am pretty sure that some of them do.   It's not sealioning. None of the messages fall under that definition and that won't change unless and until the "other party" initiates some serious engagement. > This proposal seems to remove habitat for the described behavior, and > I can't see a downside.   If you see no value in a mailing list then don't subscribe but it's quite presumptive to say that your view means the list should be handicapped in some way that might prevent it from being useful to others.   Dan. [1] https://mailarchive.ietf.org/arch/msg/ietf/ElLB2AodSLaBBvztvxj1xIzhk3U/ [2] https://mailarchive.ietf.org/arch/msg/ietf/q-abE5H-lGcydsbZqI8mz1P1ChA/ [3] https://mailarchive.ietf.org/arch/msg/ietf/R9e-sp6Sjy5KhiD9L_9_yWVoRfs/ [4] https://mailarchive.ietf.org/arch/msg/ietf/-0KIGNdrT0YdG5k4IRN0mC4rdnk/ --Boundary_(ID_nmmAiLYlXvKdtc1oj+kwLA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: 8BIT
On 8/19/20 9:05 PM, Rob Sayre wrote:
On Wed, Aug 19, 2020 at 6:10 AM Keith Moore <moore@network-heretics..com> wrote:
On 8/18/20 10:42 AM, Kyle Rose wrote:

> Can we stop using the word "toxic" in our analysis of the problem? One
> person's toxic thread is another person's debate on a serious,
> material complaint. That sometimes the discussions devolve into name
> calling by some shouldn't be used as a justification for downplaying
> the seriousness of the underlying issues.

Yes, and would people try to be more descriptive/specific as to what
they mean by "toxic"?

It seems like the ietf@ list has been damaged by "sealioning".

https://www.urbandictionary.com/define.php?term=Sealioning
 
  Yea, Richard Barnes already made that accusation [1].

  Thing is, the definition claims that sealioning means:

    "You disingenuously frame your conversation as a sincere request
    to be enlightened, placing the burden of educating you entirely
    on the other party. If your bait is successful, the other party
    may engage, painstakingly laying out their logic and evidence in
    the false hope of helping someone learn."

and that's the thing. "The other party" (that being YOU! since you're
accusing others of sealioning) never engages in any laying out of their
logic and evidence here. It's just accusations of bullying [2] and
toxicity [3]. When asked for exactly what makes words "exclusionary"
and who is excluded by them and why, the response is that we haven't
agreed yet that words can be "exclusionary" so the actual reasoning
on why one would make such an assertion-- the "logic and evidence",
an actual answer-- need not be given [4].

  Merely accusing others of bad faith is not painstakingly laying out
of logic and evidence.
I can't tell exactly which messages fall under that definition, but I am pretty sure that some of them do.

  It's not sealioning. None of the messages fall under that definition
and that won't change unless and until the "other party" initiates
some serious engagement.
This proposal seems to remove habitat for the described behavior, and I can't see a downside.

  If you see no value in a mailing list then don't subscribe but
it's quite presumptive to say that your view means the list should be
handicapped in some way that might prevent it from being useful to
others.

  Dan.

[1] https://mailarchive.ietf.org/arch/msg/ietf/ElLB2AodSLaBBvztvxj1xIzhk3U/
[2] https://mailarchive.ietf.org/arch/msg/ietf/q-abE5H-lGcydsbZqI8mz1P1ChA/
[3] https://mailarchive.ietf.org/arch/msg/ietf/R9e-sp6Sjy5KhiD9L_9_yWVoRfs/
[4] https://mailarchive.ietf.org/arch/msg/ietf/-0KIGNdrT0YdG5k4IRN0mC4rdnk/


--Boundary_(ID_nmmAiLYlXvKdtc1oj+kwLA)-- From nobody Thu Aug 20 00:32:16 2020 Return-Path: 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 469C43A0982 for ; Thu, 20 Aug 2020 00:32:15 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=gmail.com 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 cqUQxPC4GcIN for ; Thu, 20 Aug 2020 00:32:14 -0700 (PDT) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FB893A0980 for ; Thu, 20 Aug 2020 00:32:14 -0700 (PDT) Received: by mail-io1-xd2c.google.com with SMTP id v6so1197778iow.11 for ; Thu, 20 Aug 2020 00:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nMTGkbBTuFB82wqiZBlzxCU+3sv3eP6txdmOPEUKtRg=; b=V8V0WHTcgRTI8njG+Iweo90pwRe5W3lecLi4MEPdb3Ex+86NLBjtcKg4WqZWvLepFa IoV41YuxnVfTj1Z5jZ5qN7ImLyNOC/aq4qtC/jjvZVZ0+BS46nZt8DeDv5UqKfdf7+f1 Jp1Pa6R0gRl3A8MoNLhdRgzkOjgM5P0cSie0MbkFZq/y5aWcRzNVBUl0O+yYdJk8urrC yb0piyItG8vK7HBqkwMl+2W2jTRc654N5WC2AHmXSWgaLojrvFczAwLlM4MSTRnZOJH3 lVDnjcxy61i1l1CkDzUCU+vkiPn0NJaJe5T0n6/ab3WOM6qy5gXmml+YnC1jxwvw2S4g 015w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nMTGkbBTuFB82wqiZBlzxCU+3sv3eP6txdmOPEUKtRg=; b=lRxtSVDDwzNUQv9C/GXpdOTEdHWyUN5sX94RgRp9fHu7qPjZZkkhdAxE9kLGk5Q9x+ fQDKDJE0qPdo6iuADckMRK4u23qntiHDoNylScRFdg+wq0EED0fCIKRGMB2Xm5hcMHqT +xyOi8M6HPySlmzng9BUJKMEo3+qShiVNs2m1Dp2RUaUEMbtUhrlgJaeponj4rpcmMrV vt+YLasN6sXIqNz+k6JCByhYTvCJZm8LPfVX+CIdcs5IT4inPwYOoTkbf8kaHad4kL01 xBmnD2p2Dv7lZm68cl+iP6DlB7eVwVf8bkwNqMhT5H4Rusfm7kI/gTCMtO3/RG4v0cvr 2vYg== X-Gm-Message-State: AOAM533Wv4SM6oPFrLx+++jSA/eOOm7dcer4YhxN6eL5G0ljhCte+w76 UHscnE9bUSSA6fVII6T4jHNWckMnIGQnIpoCM476fdchgG4= X-Google-Smtp-Source: ABdhPJzr8No+CgCUx5h82oY5ONgi0Gcte3TdbFxgVxlSeRKJ5VThV6rbe1PmjgcHvPAWvwBI7q1qm484PTU9rkUI5GE= X-Received: by 2002:a5e:870d:: with SMTP id y13mr1509267ioj.188.1597908733241; Thu, 20 Aug 2020 00:32:13 -0700 (PDT) MIME-Version: 1.0 References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> <48f667c1-d25d-2983-72b5-336a6f800294@network-heretics.com> <7a43b7dc-9703-ad35-5a22-4155646c79f7@lounge.org> In-Reply-To: <7a43b7dc-9703-ad35-5a22-4155646c79f7@lounge.org> From: Rob Sayre Date: Thu, 20 Aug 2020 00:32:02 -0700 Message-ID: To: Dan Harkins Cc: gendispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000006daeda05ad4a1e43" Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 20 Aug 2020 07:32:15 -0000 --0000000000006daeda05ad4a1e43 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 19, 2020 at 11:42 PM Dan Harkins wrote: > > This proposal seems to remove habitat for the described behavior, and I > can't see a downside. > > > If you see no value in a mailing list then don't subscribe > I don't subscribe to that list. thanks, Rob --0000000000006daeda05ad4a1e43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Aug 19, 2020 at 11:42 PM Dan Hark= ins <dharkins@lounge.org> = wrote:
This proposal seems to remove habitat for the described behavior, and I can't see a downside.

=C2=A0 If you see no value in a mailing list then don't subscribe=

I don't subscribe to that l= ist.

thanks,
Rob
--0000000000006daeda05ad4a1e43-- From nobody Thu Aug 20 01:00:05 2020 Return-Path: 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 DD0233A097B for ; Thu, 20 Aug 2020 01:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 h7GnuRSOmSD0 for ; Thu, 20 Aug 2020 01:00:04 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1DB43A085A for ; Thu, 20 Aug 2020 01:00:03 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QFC0FBONRK37J@wwwlocal.goatley.com> for gendispatch@ietf.org; Thu, 20 Aug 2020 03:00:03 -0500 (CDT) Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QFC006MVRIWYB@trixy.bergandi.net> for gendispatch@ietf.org; Thu, 20 Aug 2020 00:59:21 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Thu, 20 Aug 2020 00:59:21 -0700 Date: Thu, 20 Aug 2020 01:00:01 -0700 From: Dan Harkins In-reply-to: To: Rob Sayre Cc: gendispatch@ietf.org Message-id: <107f5269-f842-1546-4f51-678a85bb66ea@lounge.org> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_fKHQCRpAslseJ+KtPuRaSQ)" Content-language: en-US User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local) References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> <48f667c1-d25d-2983-72b5-336a6f800294@network-heretics.com> <7a43b7dc-9703-ad35-5a22-4155646c79f7@lounge.org> X-PMAS-Software: PreciseMail V3.3 [200819a] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 20 Aug 2020 08:00:05 -0000 This is a multi-part message in MIME format. --Boundary_(ID_fKHQCRpAslseJ+KtPuRaSQ) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 8BIT On 8/20/20 12:32 AM, Rob Sayre wrote: > On Wed, Aug 19, 2020 at 11:42 PM Dan Harkins > wrote: > > >> This proposal seems to remove habitat for the described behavior, >> and I can't see a downside. > >   If you see no value in a mailing list then don't subscribe > > > I don't subscribe to that list.   You should recuse yourself from matters concerning a list that you expressly refuse to subscribe to.   Dan. --Boundary_(ID_fKHQCRpAslseJ+KtPuRaSQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: 8BIT

On 8/20/20 12:32 AM, Rob Sayre wrote:
On Wed, Aug 19, 2020 at 11:42 PM Dan Harkins <dharkins@lounge.org> wrote:
This proposal seems to remove habitat for the described behavior, and I can't see a downside.

  If you see no value in a mailing list then don't subscribe

I don't subscribe to that list.
 
  You should recuse yourself from matters concerning a list that you
expressly refuse to subscribe to.

  Dan.



--Boundary_(ID_fKHQCRpAslseJ+KtPuRaSQ)-- From nobody Thu Aug 20 01:05:13 2020 Return-Path: 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 332C23A09B7 for ; Thu, 20 Aug 2020 01:05:12 -0700 (PDT) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=gmail.com 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 LxMcxmOPG-WU for ; Thu, 20 Aug 2020 01:05:10 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0CD13A09B4 for ; Thu, 20 Aug 2020 01:05:09 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id f12so894055ils.6 for ; Thu, 20 Aug 2020 01:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IYbY5HZFWtwfvEpn0OlRHeNSDAllb2rSqZPLPzPQyKA=; b=KEZia/ttDyySi8PDbM2ukKXtL5zdb3PZqeKeN/LAQ5/gwS2JHqxgaKVk40UWoGe9lg fC+U7sNiw2M6nZHeWjFqNbQnzchIV9ZLCx2O7KgiGnmSzHTlm1ZyqpRCyovGC0JMm/wK 2TMbikaaca6lmH7Iklc0LDjkau+DHYHc+WCCbZ1QliiD6wEpwXqTS4G1h5RLJCWTNzMV IQR4E8jB0e3VQN2dc5XJzwO6nKSeMPoPhC5aFPy8KTtFZSUJfux6/dV5zQCgxuUe6Sgm E93X7GGvvL24y91wu1S3vkukXoxV3yffhfkaN06A0utvABsSFoCSQy8mJEfIUV5XkuNp skFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IYbY5HZFWtwfvEpn0OlRHeNSDAllb2rSqZPLPzPQyKA=; b=gRsu+MCZ2sU25oPdAvYKEGDdoPTvSWCcwURu9YDMdc+w9W9LzaNPVvIUEpZRJjLGsF lbWjSs6jdRjYNO86rsYP/p7hfRkjcKdwD+ckisiOE4CqmwDze94yPlqLYRxQqV+vgCGS XfxSHnwxyowSPUFmMDu8j5WxP8uF4d9wP4+qbwG5lQfxO3RZpCO8C14GzHrupHYq9bDK Vn62GwKC6G37Ddrp7o6i25JmBwQVotEJPG9M0CkaRyTJWIG9nO6Yf9atSJ/F/3jotGst WxyDbhEISzgb2PmNirTJKa9rykRGCWbppWW9zEKc2/oSEwVD7kvZRlP2TFaAQ/EfuINe PoeA== X-Gm-Message-State: AOAM533nD0CnTyNTcQ1+5XzgywkEnJwpyPFCGz11wXlLwYy1HQQg1Ktf 2P4tZjAOyVmxWVKZFKvL0ipQoIE80lVQYU5XDpcNq8Dxq7A= X-Google-Smtp-Source: ABdhPJxKR8ZR6Ivv9yshq5+JjGPyVtJuxMg3xPJrVc7DF4E9OaONpGZxu8AEKktCl7XkLfZ0A+mzKe18KSbmNmbZezA= X-Received: by 2002:a05:6e02:ea3:: with SMTP id u3mr1764726ilj.49.1597910708797; Thu, 20 Aug 2020 01:05:08 -0700 (PDT) MIME-Version: 1.0 References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> <48f667c1-d25d-2983-72b5-336a6f800294@network-heretics.com> <7a43b7dc-9703-ad35-5a22-4155646c79f7@lounge.org> <107f5269-f842-1546-4f51-678a85bb66ea@lounge.org> In-Reply-To: <107f5269-f842-1546-4f51-678a85bb66ea@lounge.org> From: Rob Sayre Date: Thu, 20 Aug 2020 01:04:57 -0700 Message-ID: To: Dan Harkins Cc: gendispatch@ietf.org Content-Type: multipart/alternative; boundary="0000000000002e463505ad4a9494" Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 20 Aug 2020 08:05:12 -0000 --0000000000002e463505ad4a9494 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 20, 2020 at 1:00 AM Dan Harkins wrote: > > > On 8/20/20 12:32 AM, Rob Sayre wrote: > > On Wed, Aug 19, 2020 at 11:42 PM Dan Harkins wrote: > >> >> This proposal seems to remove habitat for the described behavior, and I >> can't see a downside. >> >> >> If you see no value in a mailing list then don't subscribe >> > > I don't subscribe to that list. > > > You should recuse yourself from matters concerning a list that you > expressly refuse to subscribe to. > I unsubscribed a few days ago. I think I joined in 2005. thanks, Rob --0000000000002e463505ad4a9494 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Aug 20, 2020 at 1:00 AM Dan H= arkins <dharkins@lounge.org&g= t; wrote:
=20 =20 =20


On 8/20/20 12:32 AM, Rob Sayre wrote:
=20
On Wed, Aug 19, 2020 at 11:42 PM Dan Harkins <<= a href=3D"mailto:dharkins@lounge.org" target=3D"_blank">dharkins@lounge.org= > wrote:
This proposal seems to remove habitat for the described behavior, and I can't see a downside.

=C2=A0 If you see no value in a mailing list then don't subscribe

I don't subscribe to that list.
=C2=A0
=C2=A0 You should recuse yourself from matters concerning a list that you
expressly refuse to subscribe to.

I unsubscribed a few days ago. I think I joined = in 2005.

thanks,
Rob
--0000000000002e463505ad4a9494-- From nobody Thu Aug 20 05:54:48 2020 Return-Path: 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 3EC663A098A for ; Thu, 20 Aug 2020 05:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org 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 jRETcOJ4wfMd for ; Thu, 20 Aug 2020 05:54:45 -0700 (PDT) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0DB93A0985 for ; Thu, 20 Aug 2020 05:54:45 -0700 (PDT) Received: by mail-ua1-x933.google.com with SMTP id g11so533021ual.2 for ; Thu, 20 Aug 2020 05:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y0cPAMqdbmIkutdOXl/cR44tbfrzFsSOJnpaXgDaf1M=; b=LBKGWRzGMx2oUZSuwyEwT7jOBvXWPqFofy2Pkm7V63fDa7x1XLC4Py/drs+Hf2D8yj 4aQxbTVY+USqAMS0FztWwLQBPYMJ3xpTJ0zjcpb5PrejLQpuxKZ+w/Syhk5ABx7N5Uj/ G6LATg6/doFGPdXCTikMODoZzc+4X0KJbKZq8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y0cPAMqdbmIkutdOXl/cR44tbfrzFsSOJnpaXgDaf1M=; b=Qv6phi8JDsBflrJcAM4UQidyu1izceG+n0KqSpw2zseHzr4mnv1LfGjpZsCW5IGlpV Pgj3aQO81hmufOt4YakGRdW7DxTOoFJcx7rwiBIIYIAU682puF38wdWQj0tURalTjw0j jAi+g0JMYbf3ViNS3s4AOIXVOkJNsqiK+Iyse+NP9jQF4cC4oY0pnqJv6VSnm/aolwvX A41rfLWSxN8E00AQkNmCCO0ep4eZl6NgSZ4FwuSCGOLpz/gmlqnCWe/CkQz1W5onC4ij sZGfcEmNjPDNrjK34gND+gbfcYgCTlWKtaWnZSkL86Gd8vvHK1CABTvxlJFS7/ykWMWz aMjg== X-Gm-Message-State: AOAM530rTRZ7dsF7odAoi5Hgw4chnbW5O0VpaAC/Tm84EmJIh42kjgqS nfMEr1o4nFcJbtrAYewjaBZQhmIC6jsq6xECqoZUPw== X-Google-Smtp-Source: ABdhPJwe6rXUfr+FRaNEwJSlePDjjtGU5i2Y4/gqy7aeXSwMtBq9y4EZfu1jvFjWLP7SiQaUWxdomuKLTIHGoKVviNY= X-Received: by 2002:ab0:10f:: with SMTP id 15mr1553417uak.46.1597928084319; Thu, 20 Aug 2020 05:54:44 -0700 (PDT) MIME-Version: 1.0 References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> <48f667c1-d25d-2983-72b5-336a6f800294@network-heretics.com> <7a43b7dc-9703-ad35-5a22-4155646c79f7@lounge.org> In-Reply-To: <7a43b7dc-9703-ad35-5a22-4155646c79f7@lounge.org> From: Kyle Rose Date: Thu, 20 Aug 2020 08:54:33 -0400 Message-ID: To: Dan Harkins Cc: Rob Sayre , gendispatch@ietf.org Content-Type: multipart/alternative; boundary="000000000000d7c8fb05ad4e9f1b" Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 20 Aug 2020 12:54:47 -0000 --000000000000d7c8fb05ad4e9f1b Content-Type: text/plain; charset="UTF-8" > > If you see no value in a mailing list then don't subscribe but > it's quite presumptive to say that your view means the list should be > handicapped in some way that might prevent it from being useful to > others. > Indeed, quitting a list and then claiming (accurately) that it can no longer be relied on to represent IETF rough consensus is precisely begging the question. Sometimes you have to do things you don't like in service of the greater good of the organization. IMO, one of those things is paying attention to the IETF list and contributing where you have a strongly-held view so we can continue to have an organization-wide forum for establishing rough consensus (or an inability to do so: that must also be an acceptable outcome) on broad, contentious topics that aren't just document last calls. Kyle --000000000000d7c8fb05ad4e9f1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0 If you see no value in a mailing list then don't subscribe= but
it's quite presumptive to say that your view means the list shoul= d be
handicapped in some way that might prevent it from being useful to others.

Indeed, quitting a list and then claiming (accurately) that i= t can no longer be relied on to represent IETF rough consensus is precisely= begging the question. Sometimes you have to do things you don't like i= n service of the greater good of the organization. IMO, one of those things= is paying attention to the IETF list and contributing where you have a str= ongly-held view so we can continue to have an organization-wide forum for e= stablishing rough consensus (or an inability to do so: that must also be an= acceptable outcome) on broad, contentious topics that aren't just docu= ment last calls.

Kyle=

=
--000000000000d7c8fb05ad4e9f1b-- From nobody Thu Aug 20 09:19:04 2020 Return-Path: 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 8BF2A3A0933 for ; Thu, 20 Aug 2020 09:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 A25o1dU5-8AO for ; Thu, 20 Aug 2020 09:19:02 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B7E3A0964 for ; Thu, 20 Aug 2020 09:19:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 05688B95E325; Thu, 20 Aug 2020 11:18:56 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cD38gG_AIqb4; Thu, 20 Aug 2020 11:18:46 -0500 (CDT) Received: from [172.16.1.10] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 918F5B95E308; Thu, 20 Aug 2020 11:18:46 -0500 (CDT) From: "Pete Resnick" To: "Mark Nottingham" Cc: "Christian Huitema" , gendispatch@ietf.org Date: Thu, 20 Aug 2020 11:18:27 -0500 X-Mailer: MailMate (1.13.1r5706) Message-ID: In-Reply-To: <7B731DC9-5CB6-4D5B-A382-1E3179D39A9F@mnot.net> References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <20200818164957.GA86346@straasha.imrryr.org> <090f2c01-6494-7be3-4b99-280576733f35@huitema.net> <7B731DC9-5CB6-4D5B-A382-1E3179D39A9F@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 20 Aug 2020 16:19:04 -0000 It sounds to me like Christian is saying, "The lack of rules of order for the IETF list is a problem", and it sounds like that is a statement with which Mark would probably agree. I'm also guessing that the two of you would also agree that the "SAA SoP" is not a workable set of rules of order. So it sounds like the counter-proposal to Mark's would have to say what kinds of rules of order might work. That might be good to explore. I'm definitely hearing a contingent saying that they don't want Mark's proposal moving forward, but if I think about DISPATCHing it, I'd like to hear if work on some form of change to the structure of or operational rules of the IETF list would be acceptable to that contingent. Is there something here people think would be useful, and if so, in what forum should it be worked on? Cheers, pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best On 19 Aug 2020, at 0:35, Mark Nottingham wrote: > Hi Christian, > > I'm not going to respond to every message on this thread, as I want to > hear what others think. > > I think we agree that the question at hand is reconciling the nature > of the discussion with the need for it. My draft is one proposal; > there maybe others, and I'm happy to discuss changing mine. I wrote > this one down because it's pretty clear (at least to me) that imposing > rules of order on this list isn't possible, because many people are > unwilling to change how they use or think about it. If I'm wrong about > that, that's great. > > Regarding 'Mark's proposal also does away with any notion of an online > general assembly' -- My expectation is that even if the IESG and > other leadership would be told that they don't have to listen to > ietf@, they still would -- provided that the list didn't become mired > in endless acrimonious cycles, as it has of late. De-emphasing the > list also restores some balance between those that use it to amplify > their voices and those who are turned away from such activity. > > Perhaps that goes too far, and there does need to be an expectation > that leadership will be on the list. If that's the case, it's > important to recognise that this becomes a selector for leadership -- > if you can't 'take it' on the ietf@ list, you're not fit for > leadership. That will in turn reduce the diversity of work and > participants in the IETF over time. > > Cheers, > > >> On 19 Aug 2020, at 3:32 am, Christian Huitema >> wrote: >> >> I am not entirely convinced by Mark's draft either. My personal >> assessment is that we have many problems: >> >> * The IETF list acts as the offline general assembly, but without any >> rules of order. We would not run a meeting of 1000 people without any >> such rules, and for example we use mike queues and time limits during >> the plenary. The lack of order leads to poor behavior and reduced >> utility. >> >> * The IETF list also acts as the IETF lobby, a place that newcomers >> might join in order to sense the pulse of the organization. But we >> are conducting a permanent and sometimes very loud general assembly >> in the lobby, and that scares visitors away. >> >> * To expand on the previous point, the tolerance for loud discussions >> naturally selects for loud spoken and loudness tolerant individuals, >> typically oldtimers. It turns away other types of participants, >> contributing to lack of renewal and lack of diversity in the >> organization. >> >> * As Mark points out, the list membership is a fraction of the IETF >> participants, which makes it a rather unrepresentative general >> assembly. But that may well be a consequence of the other issues. >> >> Mark's proposal addresses the "rules of order" issue by directing >> discussions to the gendispatch WG, and then possibly to specialized >> WG. The advantage is that WG chairs can and do impose discussion >> rules. We have examples that it works, e.g., moving the RFC-ED >> discussion from the IETF list to a specialized group. But Mark's >> proposal also does away with any notion of an online general assembly >> -- the IETF list is left to its own devices, some kind of playground >> for people who like loud debates, and the IESG is told that it just >> does not have to listen. That seems sub-optimal, because feedback is >> indeed useful. >> >> If I am right -- :-) -- the main missing component is some kind of >> "rules of order" for the IETF list, similar to the mike lines and >> time limits that we have in working groups or in the physical >> plenary. This requires some authority to enforce the rules, an >> authority that should be separate from the IAB/IESG leadership if we >> want an avenue of feedback for that leadership. >> >> We may also consider not washing our dirty laundry in the front >> lobby, i.e., separating the "social discussion" and "plenary" >> functions. >> > > -- > Mark Nottingham https://www.mnot.net/ From nobody Thu Aug 20 11:00:02 2020 Return-Path: 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 DB0A83A0FA0 for ; Thu, 20 Aug 2020 10:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=akamai.com 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 M3REnVhbsbn7 for ; Thu, 20 Aug 2020 10:59:58 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36B63A0F8A for ; Thu, 20 Aug 2020 10:59:58 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 07KHuZva003149; Thu, 20 Aug 2020 18:59:48 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=wg2gTODxdSboYyyoik4kfRutLVuKW5p9n9Aj5oFnsbw=; b=Jh6l00ieriYaNibkinhsz57M9smH42k/1hmfJ1gEhJgqv2dB2IDsbkq3ERXTnAcc8cHd AaXuT0K0sOs6vh9NpJKLGh/bJToY6Uee4lsSBt9DQVo8+1iIOgwb6WHcJjDH/7lbTv7Y 5tSeDJA3IPH/i8cUDizFgKYLW9CSPb72oL11eVtYTmsspGgc+Fe+VNYx8jbRXERBSvaX lSa80yhAJcXqFIzKQ7sQkm9SsCbVfffm4dIgqPWmvedqo/EZfvt9c+nvxTpDCpzfx6Oc TrfoPMOU8vPDNvnFCf5O9UzrNVp8DfbRh/oSHeTmFAH/mvblyguYBIOKBIS2fNjJ+WMx iA== Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 3304m659cc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 Aug 2020 18:59:48 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 07KHngbE026096; Thu, 20 Aug 2020 13:59:47 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint3.akamai.com with ESMTP id 32xb1y3j87-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 20 Aug 2020 13:59:47 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 20 Aug 2020 13:59:46 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1497.006; Thu, 20 Aug 2020 13:59:46 -0400 From: "Salz, Rich" To: Pete Resnick , Mark Nottingham CC: "gendispatch@ietf.org" , Christian Huitema Thread-Topic: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt Thread-Index: AQHWdQnnOx27rqM9kEa/cTAscvAiaKk9n7iAgAADR4CAABoZAIAAmxeAgAALxoCAAMofAIACRfiA///ZQAA= Date: Thu, 20 Aug 2020 17:59:46 +0000 Message-ID: References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <20200818164957.GA86346@straasha.imrryr.org> <090f2c01-6494-7be3-4b99-280576733f35@huitema.net> <7B731DC9-5CB6-4D5B-A382-1E3179D39A9F@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.29] Content-Type: text/plain; charset="utf-8" Content-ID: <2B818D8874A58045897B8F2404DE84A1@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-20_03:2020-08-19, 2020-08-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 bulkscore=0 mlxscore=0 mlxlogscore=601 adultscore=0 phishscore=0 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008200144 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-20_03:2020-08-19, 2020-08-20 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 mlxscore=0 spamscore=0 malwarescore=0 priorityscore=1501 adultscore=0 phishscore=0 impostorscore=0 suspectscore=0 bulkscore=0 mlxlogscore=539 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008200145 Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 20 Aug 2020 18:00:00 -0000 PiAgSSdkIGxpa2UgDQogICAgdG8gaGVhciBpZiB3b3JrIG9uIHNvbWUgZm9ybSBvZiBjaGFuZ2Ug dG8gdGhlIHN0cnVjdHVyZSBvZiBvciANCiAgICBvcGVyYXRpb25hbCBydWxlcyBvZiB0aGUgSUVU RiBsaXN0IHdvdWxkIGJlIGFjY2VwdGFibGUgdG8gdGhhdCANCiAgICBjb250aW5nZW50Lg0KDQpO b3QgdG8gbWUuICBNYXliZSByZXZpc2l0IGluIHNpeCBtb250aHMsIG9yIGEgY291cGxlIG9mIG1v bnRocyBhZnRlciB0aGUgInByb2JsZW1hdGljIGxhbmd1YWdlIiBkcmFmdHMgYXJlIGRpc3BhdGNo ZWQuDQoNCg0K From nobody Thu Aug 20 12:12:55 2020 Return-Path: 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 162B63A12ED for ; Thu, 20 Aug 2020 12:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 U9g_FEBjTm4L for ; Thu, 20 Aug 2020 12:12:53 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798FA3A12E9 for ; Thu, 20 Aug 2020 12:12:35 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 9F3F5542 for ; Thu, 20 Aug 2020 15:12:34 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 20 Aug 2020 15:12:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=IEOjGsEwcGHlfNiRDSxv40bblISjDcp0xUwUF7bQV FE=; b=b/SwXVT6umB2fMP8vomHdXaEB6Aahhq9lxXLqqUdkrZ00cGnIk/DWpaGN ypCAP0S1xNbsloWprZ1mBFgRcUq+rbbCqx072QVycB2UWOAaME1LaQxnQ6LzLUA3 iCipfKJY8EVrEbUpxtJaniM2lMptMDSqMVx6Qmxpn/i6QjFnecjqCQ5OssnUjuhc Y7YJkxyrpN1Xh9l1crpgsIfxt4PVQJSa8EjxI+83YcmGRlwp1espOOA3PyzR6jQu Wh1UZ9xuvalHc3U1W0Vj73llWQD+d5uo9Al7XxawoA01q+4xS8ilDGj2P6+gGDrK A5NY32chq1HrNRS2V6uPUxeKwb3QQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddutddgjeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeehhfeutdehfe fgfefghfekhefguefgieduueegjeekfeelleeuieffteefueduueenucfkphepuddtkedr vddvuddrudektddrudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 60B9D3060067 for ; Thu, 20 Aug 2020 15:12:33 -0400 (EDT) To: gendispatch@ietf.org References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <20200818164957.GA86346@straasha.imrryr.org> <090f2c01-6494-7be3-4b99-280576733f35@huitema.net> <7B731DC9-5CB6-4D5B-A382-1E3179D39A9F@mnot.net> From: Keith Moore Message-ID: <61bf9fa3-803e-c4e1-e77f-d29b50d0730f@network-heretics.com> Date: Thu, 20 Aug 2020 15:12:32 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Gendispatch] Proposed list reorganization (was: I-D Action: draft-nottingham-discussion-recharter-00.txt) X-BeenThere: gendispatch@ietf.org 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: Thu, 20 Aug 2020 19:12:55 -0000 On 8/20/20 12:18 PM, Pete Resnick wrote: > It sounds to me like Christian is saying, "The lack of rules of order > for the IETF list is a problem", and it sounds like that is a > statement with which Mark would probably agree. I'm also guessing that > the two of you would also agree that the "SAA SoP" is not a workable > set of rules of order. So it sounds like the counter-proposal to > Mark's would have to say what kinds of rules of order might work. That > might be good to explore. > > I'm definitely hearing a contingent saying that they don't want Mark's > proposal moving forward, but if I think about DISPATCHing it, I'd like > to hear if work on some form of change to the structure of or > operational rules of the IETF list would be acceptable to that > contingent. Is there something here people think would be useful, and > if so, in what forum should it be worked on? I do think some changes might be appropriate, but don't think of them as limited to, or specifically scoped by, changes to the rules of order. 1. I believe that the IETF needs a "center", i.e. a list that nearly everyone participating in IETF will want to subscribe to. That list should be devoted to topics of relevance to the Internet and/or IETF, and the purpose of the list should be to make IETF participants generally aware of those topics and related issues, so that we're all more-or-less on the same page.  (That's not to say that everyone should agree on how to address those issues, just that there's a set of things that probably everyone who participates in IETF should be aware of.)   IMO, there should be room for discussion on that list - it should not be announce-only - but perhaps there should be some measures to keep that discussion (a) on-topic and (b) relatively low-volume. Especially (b) is implied by the desire to have nearly everyone who participates in IETF to be subscribed to this list.   Since Censorship Is Bad, perhaps there should be a designated separate "overflow" list so long discussions can be redirected there to keep the main list volume low but without silencing people. (Perhaps the ietf-details@ list proposed below would be appropriate for that.) (It's possible that this list would need to be moderated in order to keep volume low, but I hope not because then it might degrade into just another announce list.   IMO it should be limited to topics of broad interest to the IETF community, but NOT only the topics that I* think are relevant.   It might be tricky to maintain that balance.) 2. In addition there is a need to have a place for potentially contentious and/or lengthy discussions - including Last Calls, WG chartering, policy discussions (however the policies are implemented), and public discussion of how IETF is run.   I will tentatively call it ietf-details@ (as in "the devil is in the details") though ietf-swamp@ might also be a good name.   This list would serve as a place to publicly collect input that IESG and other IETF participants can use to gauge the degree of consensus on a particular topic, but also for discussion of such topics - especially efforts to refine points of contention, and to identify potential common ground on which rough consensus might eventually be built.   This list would be separate from the main IETF list so that not everyone who subscribes to ietf@ would have to see it.    However anyone who subscribes to the main IETF list should be able to post to the ietf-details@ list without a separate subscription to that list.   Non-subscribers to ietf-details@ who occasionally want to wade into the swamp should be free to do so.   They can read messages on the ietf-details@ list via the archive or the IMAP server.   Occasionally it might be appropriate to post a message to ietf@ of the form "discussion of topic X is taking place on the ietf-details@ list, you can see it in the archive at ". Both of these lists would be subject to ordinary rules of decorum, but the ietf@ list would have a narrower range of acceptable topics as well as perhaps some limits on number of messages posted on any particular topic. Part of the idea here is to let people be "in the loop" even if they don't want to be "in the swamp".   Part of the idea is to minimize the number of occasions in which it's necessary to make value judgments about the propriety of conversations in order to avoid discouraging relatively casual participants. (Of course if the above structure were adopted it would be appropriate to update RFC3005 to reflect that.) 3. Regarding rules of order, I suspect that only slight tweaks are needed.   First, the SAAs should not be either chosen by or act under the direction of the IETF Chair.  IMO they should act as independent and ideally impartial moderators, but adhere strictly to standards already established except in the rare occasion when they don't know how to interpret those standards... then they should consult IAB.   Second, there needs to be a clear process for appeal of SAA actions (presumably to IAB) rather than just a vague "complaints ... should be referred to the IAB" as currently in 3005.   Third, IMO it would be beneficial to define the standards of decorum more precisely, and particularly to avoid ambiguous words like "[un]professional" (as well as "[un]helpful", "toxic", "tone", etc.) which may mean very different things to different people, and which can therefore be enforced arbitrarily and in a potentially discriminatory fashion, according to the whims of the enforcers or people who direct them.  Fourth, perhaps SAAs should have a broader range of actions available to them when moderating the ietf@ list - e.g. redirecting a conversation to the ietf-details@ list. 4. I'm wondering if it would also be useful to publish a document on the subject of "making effective use of IETF email lists" which suggests things like: (a) using an email reader that allows threaded reading (so readers can ignore entire threads that they're not interested in and easily peruse the ones they are interested in), (b) using a separate email address from one's normal work address so that the work address isn't flooded with traffic, (c) using subfolders and subfolder addressing when available, (d) how to reply effectively, (e) when to move a discussion to private mail, etc. 5. More ambitiously, I'm thinking it's also possible that the current hodgepodge of ietf lists (ietf@, ietf-announce@, last-call@, ...) could use some cleaning up and potential reorganization with the idea of making it easier for IETF participants to keep track of the things they're interested in, without having to wade through volumes of material they're not interested in.   For instance, a better ability to fine-tune which announcements one receives, say per-area or per-WG or per-document, might be useful. More ambitiously, some or all of these topics might be appropriately deferred to a working group tasked with making IETF communications more accessible / easier to use. Keith From nobody Thu Aug 20 13:53:40 2020 Return-Path: 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 268C73A140C for ; Thu, 20 Aug 2020 13:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: 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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=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=gmail.com 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 Fj6LqT89v2gw for ; Thu, 20 Aug 2020 13:53:36 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D63CD3A140B for ; Thu, 20 Aug 2020 13:53:36 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id d22so1637278pfn.5 for ; Thu, 20 Aug 2020 13:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=Yppq7CqJUqcVA48zdwbP5hH+wEKpg/w2tCVir/8zIIU=; b=pbdWf7fpEt9QanvcksH0N5fdhbcZ7kzR4M//CxqtJP2GIvYBbDscHRJTHtaErw1XWu 5ZaSHear5CET+IU3oPX1dtrpHVP+iP/R1Rl3XthbrfQxg5k0tLZGQqaSljae5Mh+QfqJ +2G/txKyhD5r28T1gsj47wSPNuWjf0MSwzQBgOMOsrEWbO/JqbDYQcEVjD3Z7HC6SKvi r6SD61mDS3vPY2Mnk6c2klVrSs8bjFB3KidT7VumVavT93KVJoGKBbIRbq1rcDSF1Rbo dE3mpPCVWEdZz306KpbALyQshvzMK/vR6nr9N11VWM0yCnt9teFq2PjEkuTWUGN0Ivq8 PlTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=Yppq7CqJUqcVA48zdwbP5hH+wEKpg/w2tCVir/8zIIU=; b=X9v1vNxGQnB+Oksb0ASkVp/dZfq22w8PAA0c8UB0HL0u6eI6PdsBvtSCNJn0XAjRPd kdb6nI9+CTq26tjYnko8hu6RGkcWR7L8hnKWUOsxl9RlrFCqwKXtQcYysPbabNosu2WJ j7zlJl6FOm01Rmc+FJY/xD5pVQOHGighhLhvn8KCPbNY0TN9iMbW9A+5tivYmfOQ3cXh jiFHsoBT8aU8rQixme9Zedkk8PAGVbuDZAt9h2d/ox6hOdAhem9TtzcbHpKas9pUrU+x jfJ1osqBoCCEdXe5TI+3fLOc0qx7AwjKZGkZy8DK2TDzlrWBi5FGxtSnHT3mReaK2Od+ 5gPg== X-Gm-Message-State: AOAM532tKbH84NtCZrT37hQaJxGx/LObY/Ei5FKXLDTiu4nxyWLOuTlh YswwbyWhhslEGaopVeYB/YBrek4Pdymv8g== X-Google-Smtp-Source: ABdhPJwvZAaHrKwL9CZocwmJzHYVU4pFDTmjLCqqrnQHtzC59H1BWgswiljBRUsBKX3Ev0ReCaz/7A== X-Received: by 2002:a62:8815:: with SMTP id l21mr389983pfd.309.1597956815870; Thu, 20 Aug 2020 13:53:35 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id n26sm3757803pff.30.2020.08.20.13.53.34 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Aug 2020 13:53:35 -0700 (PDT) To: gendispatch@ietf.org From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Fri, 21 Aug 2020 08:53:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Gendispatch] draft-carpenter-ietf-chair-tasks X-BeenThere: gendispatch@ietf.org 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: Thu, 20 Aug 2020 20:53:38 -0000 Hi, Somebody kindly reminded me today about an expired draft of mine, and I found myself wondering whether it is a useful one to update and discuss. That seems like a question for GenDispatch. https://tools.ietf.org/html/draft-carpenter-ietf-chair-tasks-00 I remember being disappointed at the time by the lack of interest in the draft, which seems relevant as NomCom starts its work. Is there any interest today? Regards Brian Carpenter From nobody Thu Aug 20 15:22:40 2020 Return-Path: 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 6DE5A3A1458 for ; Thu, 20 Aug 2020 15:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.047 X-Spam-Level: X-Spam-Status: No, score=-3.047 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.949, SPF_HELO_NONE=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=gmail.com 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 HWBEWN3AZFDL for ; Thu, 20 Aug 2020 15:22:36 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D9783A1454 for ; Thu, 20 Aug 2020 15:22:36 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id mt12so60140pjb.4 for ; Thu, 20 Aug 2020 15:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=9XjnAS0tmzfWAH5kIBCrtP0fBnrr6KHUThMsVrpr5Gk=; b=t8UC/ckIyIOqHc5p8YJHNxXs8Ni1CXcuwF4cbmBsHWAp0CBHcJvORzKncOt85G0ah0 n3CM+OK2Tv4TmsDFkyGCQGEliLIeF1/yctmuURE4J7B7Q9OlOnJHqXYKH1kGg0Hrl46E XC9fukeUgT6rEu3zI9nROdCjBZhQCqNNKnJEmt98oL5IU4gCu8pOOPIKq6M4Uk7OEcIT lriWVHB0lVOeb/hKJneeKP0O5+L8QLS0MlOIDT0cDTHjFotL0qnmwxuO9XgEqhT5ZHOS IEjU44+A16s9XAUOafzRFL/hsFfj4JPUbuICGIDljdec/eENert/kPy1ihl9Zd6sM+zL qSow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=9XjnAS0tmzfWAH5kIBCrtP0fBnrr6KHUThMsVrpr5Gk=; b=PUOKxpfuO7mB8RANovsabjtnglqnolLu9RIUBuCjjlJ+ok/erhYgDubx6eC/uzGDo0 dah80AJhd8oCg5wwmv6lZ0MX9RyFVFdqIHq9/gnCmaTaxGvH++yR47iFFQq8NlMhD85p 0NcAFR8loOMXp9As06tyxzJv//nj1MTbQVd9pAs6izbU6F7NA7n3bMEBngWLv7Kc/1SN NP8DNOis5tXzIEQaaqN1xHvfwcAyA+MdEhUtpEFHWi8MjBXiJEGnyV9aw5Cvkz9D/C8X YwWLw18b7TYgMnye1bolcxnt3cmI8VxlhbKh/AdvdkFHaATsFhR9OrVEpgZUTS6BvHlZ lexg== X-Gm-Message-State: AOAM530B1NGCOGMYOFx72vNA1mbNQXBKu7toJw89c6jFuIZQ1kEUCdtM og6v5yM+JmfQCc/P/31nFizpv7ZVlZXhvw== X-Google-Smtp-Source: ABdhPJyhFpYO54+M+pYPGCKSh5qCg8graAqerXPv9rDfq6slAaDKyqZ6Q0TROROvReE+ti3+jxi96Q== X-Received: by 2002:a17:902:b282:: with SMTP id u2mr383341plr.225.1597962155522; Thu, 20 Aug 2020 15:22:35 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id cv3sm913pjb.45.2020.08.20.15.22.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Aug 2020 15:22:34 -0700 (PDT) To: Rob Sayre , Keith Moore Cc: gendispatch@ietf.org References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> <48f667c1-d25d-2983-72b5-336a6f800294@network-heretics.com> <25b91252-14a1-2267-06eb-293779df0be6@network-heretics.com> From: Brian E Carpenter Message-ID: <869d2af1-c20f-9653-62f8-b369d135d29f@gmail.com> Date: Fri, 21 Aug 2020 10:22:31 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 20 Aug 2020 22:22:39 -0000 On 20-Aug-20 16:25, Rob Sayre wrote: > On Wed, Aug 19, 2020 at 9:11 PM Keith Moore > wrote: >=20 > On 8/20/20 12:05 AM, Rob Sayre wrote: >=20 >> >> It seems like the ietf@ list has been damaged by "sealioning". >> >> https://www.urbandictionary.com/define.php?term=3DSealioning >> >> I can't tell exactly which messages fall under that definition, bu= t I am pretty sure that some of them do. >=20 > I generally find it unhelpful in the extreme to presume bad intent = in the absence of a preponderance of evidence.=C2=A0 >=20 >=20 > That is pretty much the definition of the trust that sealioning takes a= dvantage of. >=20 > I favor removing the habitat. I don't want to guess at anyone's motivat= ions, and I don't see a lot of productive input coming from the ietf@ lis= t that=C2=A0couldn't be delivered elsewhere. I have to invoke one of the first things we all learned in CS: Any proble= m can be solved by an extra level of indirection. And its corollary: Afte= r some time, the problem will come back, one level down. In other words, = whatever vehicle you use for discussing IETF-wide issues will end up in t= he same state: some discussions either get out of hand, or upset some peo= ple, or both. Let's not just drive this problem elsewhere. Fix what's wrong with the SA= A mechanism. Keith's message would be a good basis for an I-D. Regards Brian From nobody Thu Aug 20 17:32:37 2020 Return-Path: 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 98D863A14C9 for ; Thu, 20 Aug 2020 17:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=R5xwD6MA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fESyZN1L 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 KCdfh3JXplMR for ; Thu, 20 Aug 2020 17:32:32 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6543A3A1507 for ; Thu, 20 Aug 2020 17:32:12 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 4DAEA5C02A0; Thu, 20 Aug 2020 20:32:11 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 20 Aug 2020 20:32:11 -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=fm3; bh=7 uK0OeB8prYUI3pCzXtj8jKTv6WoIfreuGThRQ6PwSo=; b=R5xwD6MANfG4RYdU7 kH1Wobdrgs672yyfRaD2ngjUaRiCyqlCEv+biMPgYQ/fJBT4QlLg0c75g2owvE9d qQiShEJHDnxt7MPXLOLkg4vuDiYn4/0HzKOTXkvOe3JGrOZCmcUa4k+2jOcgd2BS ieG7dx4HthsQ0eqThL/oaozc2cjJ/DUVDvmoeoPC7/ilh16xXV0Z1KsvwuTl9dOU t537K93+1iH0BLq3AWwBy/tBT4hJHkYixEW9MXnieh/UZZ8nWgU4cWUjWiI1l/Jb zboCS0yZxKLOUXWM+bf3t3IGzC1KLVd5KPgA/DtDkaHbCapKIDtAlbZsqzHcE/2p wSrKA== 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=fm3; bh=7uK0OeB8prYUI3pCzXtj8jKTv6WoIfreuGThRQ6Pw So=; b=fESyZN1LPs0DgYieo3N6BFYqCxn4Oin7g0sbnFFQb6WawZDJ/v3cHUE+P tAOSoy1+ko+NOrnMrMFFl5UB2HreWC0krZLOAULcPtCXLcbnFc51LI4zh+/cCZZ5 6u6HJrEMyN7XKYiY+FbCLDQ9S8dt4pzYxcalpCGl3A0JVGeoHRQqLZ6pYmYujea4 AQ9EUW//yLOuK1LD0v2mP0qEe4Z9DvZ9CDhfhioqW+ofMDwfhY09m3ZKtTbGip09 aTDOt453DecBAI7lDrdfaoU/pN+IQh2yGQ7vhRaTohQoIu9TLYY7wGk779sidlat 6nriRn0fzBMd8dEQtI2nzT5XaAYng== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudduuddgfeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeevffffhfduteevvefhueffieegtdeutdehffeltefffedttdeggeejheeiueet teenucffohhmrghinhepmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvd ehudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehm nhhothesmhhnohhtrdhnvght X-ME-Proxy: 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 2EAF7328005D; Thu, 20 Aug 2020 20:32:08 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Mark Nottingham In-Reply-To: Date: Fri, 21 Aug 2020 10:32:06 +1000 Cc: Christian Huitema , gendispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <20200818164957.GA86346@straasha.imrryr.org> <090f2c01-6494-7be3-4b99-280576733f35@huitema.net> <7B731DC9-5CB6-4D5B-A382-1E3179D39A9F@mnot.net> To: Pete Resnick X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Fri, 21 Aug 2020 00:32:35 -0000 Hi Pete, > On 21 Aug 2020, at 2:18 am, Pete Resnick wrote: >=20 > It sounds to me like Christian is saying, "The lack of rules of order = for the IETF list is a problem", and it sounds like that is a statement = with which Mark would probably agree. I'm also guessing that the two of = you would also agree that the "SAA SoP" is not a workable set of rules = of order. So it sounds like the counter-proposal to Mark's would have to = say what kinds of rules of order might work. That might be good to = explore. I'd like to believe that's a way forward, but am somewhat pessimistic = about its chances of success.=20 My reading of the situation is that there are a few somewhat conflicting = purposes for the ietf@ list, and that blocks any meaningful progress. Many see the IETF list as having a plenary function; it is where the = organisation comes together to discuss matters of import to everyone. = The IESG can get a sense of the community there, participants can hold = them to account and raise new ideas, and so on. As Christian and others have pointed out, a plenary function needs rules = of order for even mildly contentious discussions; otherwise, the loudest = can drown out other voices, arguments become circular, and everything = becomes generally unproductive. Some people also see the IETF list as a Speakers' Corner; the priority = is on everyone being able to express themselves. The boundaries of = acceptable discourse are therefore broad; it's OK to send a message = dripping with sarcasm, ascribing motives to others, meandering about = conspiracy theories, and so on. It's also OK in this view to respond to = such messages with disdain, etc. -- which brings what one could call = 'robust discourse' or 'endless ratholing' depending on your disposition. These functions are in obvious conflict.=20 Of course, some plenaries do serve both functions -- e.g., most = legislatures allow a member to speak about whatever is on their mind. = However, they always impose limits on that right; e.g., members' = speeches only happen at certain times, can only be of a certain length, = and there are still ethical requirements that, if violated, can be = punished. On the IETF list, we don't have effective limits; one can post on any = given topic ad nauseam, and as we've seen recently imposing order is = tricky (the SAA has been given very blunt tools. I won't defend the = recent attempt to use them, but I do sympathise with their position). I speculate that this is because while some people see the IETF list as = a Speakers' Corner, others see it through the lens of a modern = workplace, where behaviour suitable to a Speakers' Corner would often be = seen as unprofessional at a minimum, and cause for dismissal in some = cases. I suspect that some believe they shouldn't be subjected to = unprofessional behaviour as part of their job; beyond just 'standards = professionals', _any_ developer that comes to engage with IETF = technology is also potentially exposed to such unprofessional behaviour, = and may avoid some parts of the organisation or the whole of it as a = result. I suspect that some people think that that's not a good outcome for the = IETF and the Internet, and that others are fine with it. There are some = underlying tensions here regarding not only professional behaviour, but = also academic freedom, individual vs. collective rights, etc., before = you even get to issues of Internet governance. I'm sure that this will = all be rich fodder for social scientists for quite some time. This is why I made my proposal; it keeps the IETF list as a Speakers' = Corner, but moves the plenary function elsewhere. That doesn't mean the = plenary (or the leadership) is unaware of what happens on the Speakers' = Corner; it's just that they're different venues. > I'm definitely hearing a contingent saying that they don't want Mark's = proposal moving forward, but if I think about DISPATCHing it, I'd like = to hear if work on some form of change to the structure of or = operational rules of the IETF list would be acceptable to that = contingent. Is there something here people think would be useful, and if = so, in what forum should it be worked on? I'd characterise many of the negative responses as "I don't have that = problem, so it's not worth changing anything." Perhaps we could get a = description of the problem agreed to -- *if* those folks are willing to = cede that just because they don't personally have a problem, others = still might encounter it. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Thu Aug 20 18:38:48 2020 Return-Path: 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 EC69E3A0FDB for ; Thu, 20 Aug 2020 18:38:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 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, NICE_REPLY_A=-0.949, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com 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 pqcxaGglCCYq for ; Thu, 20 Aug 2020 18:38:45 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F9943A0FD2 for ; Thu, 20 Aug 2020 18:38:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4BXkgn0FDHz6GFxR; Thu, 20 Aug 2020 18:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1597973925; bh=OHafNdhvE23CoMOZHiCcxfQcOMRyv3sNkwJ7C6BN6gY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ffBEKF+TegcdQqFUrFb4i/ug/RBw9aEtj7qp/9y2lhm1ayTogx/7/YqU0fjMV2nEQ Ip0EYJWLdfZIMNgo9OhNxT9a1ACpkxhTP4qBv6HkrtXC/Y6nvehifv2tFyBQyavMoB oe2C+t/co3BYmnyY8zOcrH0d7HpKqDq2sEb/aY5E= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4BXkgm3Wwlz6G9lH; Thu, 20 Aug 2020 18:38:44 -0700 (PDT) To: Mark Nottingham Cc: gendispatch@ietf.org References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <20200818164957.GA86346@straasha.imrryr.org> <090f2c01-6494-7be3-4b99-280576733f35@huitema.net> <7B731DC9-5CB6-4D5B-A382-1E3179D39A9F@mnot.net> From: "Joel M. Halpern" Message-ID: <0778e014-1a7a-9128-7fc8-20f70e2783a3@joelhalpern.com> Date: Thu, 20 Aug 2020 21:38:43 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Fri, 21 Aug 2020 01:38:47 -0000 While it is possible that some people see the ietf@ list as a speakers corner with the terms you describe, my understanding is that the IETF has explicitly said that things like "ascribing motives to others" are not permitted on any IETF list. I think some of the other behaviors you list would also be prohibited by our existing standards of conduct. Whether those standards are enforced well on the ietf@ list, or for that matter on all WG lists, is a different question from whether we have claimed that they apply. Yours, Joel On 8/20/2020 8:32 PM, Mark Nottingham wrote: > Hi Pete, > >> On 21 Aug 2020, at 2:18 am, Pete Resnick wrote: >> >> It sounds to me like Christian is saying, "The lack of rules of order for the IETF list is a problem", and it sounds like that is a statement with which Mark would probably agree. I'm also guessing that the two of you would also agree that the "SAA SoP" is not a workable set of rules of order. So it sounds like the counter-proposal to Mark's would have to say what kinds of rules of order might work. That might be good to explore. > > I'd like to believe that's a way forward, but am somewhat pessimistic about its chances of success. > > My reading of the situation is that there are a few somewhat conflicting purposes for the ietf@ list, and that blocks any meaningful progress. > > Many see the IETF list as having a plenary function; it is where the organisation comes together to discuss matters of import to everyone. The IESG can get a sense of the community there, participants can hold them to account and raise new ideas, and so on. > > As Christian and others have pointed out, a plenary function needs rules of order for even mildly contentious discussions; otherwise, the loudest can drown out other voices, arguments become circular, and everything becomes generally unproductive. > > Some people also see the IETF list as a Speakers' Corner; the priority is on everyone being able to express themselves. The boundaries of acceptable discourse are therefore broad; it's OK to send a message dripping with sarcasm, ascribing motives to others, meandering about conspiracy theories, and so on. It's also OK in this view to respond to such messages with disdain, etc. -- which brings what one could call 'robust discourse' or 'endless ratholing' depending on your disposition. > > These functions are in obvious conflict. > > Of course, some plenaries do serve both functions -- e.g., most legislatures allow a member to speak about whatever is on their mind. However, they always impose limits on that right; e.g., members' speeches only happen at certain times, can only be of a certain length, and there are still ethical requirements that, if violated, can be punished. > > On the IETF list, we don't have effective limits; one can post on any given topic ad nauseam, and as we've seen recently imposing order is tricky (the SAA has been given very blunt tools. I won't defend the recent attempt to use them, but I do sympathise with their position). > > I speculate that this is because while some people see the IETF list as a Speakers' Corner, others see it through the lens of a modern workplace, where behaviour suitable to a Speakers' Corner would often be seen as unprofessional at a minimum, and cause for dismissal in some cases. I suspect that some believe they shouldn't be subjected to unprofessional behaviour as part of their job; beyond just 'standards professionals', _any_ developer that comes to engage with IETF technology is also potentially exposed to such unprofessional behaviour, and may avoid some parts of the organisation or the whole of it as a result. > > I suspect that some people think that that's not a good outcome for the IETF and the Internet, and that others are fine with it. There are some underlying tensions here regarding not only professional behaviour, but also academic freedom, individual vs. collective rights, etc., before you even get to issues of Internet governance. I'm sure that this will all be rich fodder for social scientists for quite some time. > > This is why I made my proposal; it keeps the IETF list as a Speakers' Corner, but moves the plenary function elsewhere. That doesn't mean the plenary (or the leadership) is unaware of what happens on the Speakers' Corner; it's just that they're different venues. > > >> I'm definitely hearing a contingent saying that they don't want Mark's proposal moving forward, but if I think about DISPATCHing it, I'd like to hear if work on some form of change to the structure of or operational rules of the IETF list would be acceptable to that contingent. Is there something here people think would be useful, and if so, in what forum should it be worked on? > > I'd characterise many of the negative responses as "I don't have that problem, so it's not worth changing anything." Perhaps we could get a description of the problem agreed to -- *if* those folks are willing to cede that just because they don't personally have a problem, others still might encounter it. > > Cheers, > > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Thu Aug 20 21:11:56 2020 Return-Path: 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 A138D3A10B7 for ; Thu, 20 Aug 2020 21:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pG6E1enqZGgv for ; Thu, 20 Aug 2020 21:11:54 -0700 (PDT) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C183A10B0 for ; Thu, 20 Aug 2020 21:11:54 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id f12so355438ils.6 for ; Thu, 20 Aug 2020 21:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vvhAO+sqqKiSE/A3wnC/4mXhzQmAWaxRSPiJtcXNa1s=; b=lbiCo7+Z+uf37fd6w9lE+2A7K7VqxpNVGWd5ruFKt82J9eZB0az7YBCXZfzleUB5B2 sYPdehLY8sI1T5sp0IE9Fh/MajX5V365oWubi/xvkdWwJJ2owhWNNwt6ao0YMfNfcmm9 qzymaS6Pvr/Nqxg1r7/4m7oG65pAbRBMzxIoj+S+YXcWbA7JcNTBrM7YSrQzljXYZp8L uOaykZXvk7LMgYABqS8XHRldlb64wgcS3/6N74WlJnF/Gf6x5MptHCsKAh4Fc7+vHSCo xrdwZDvR4ECY+R7i0e9d0oC1eE9HgSzrK8aJ7kJFljbI2SoWuGU/Us4xBJkPnFsegCrl 3iNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vvhAO+sqqKiSE/A3wnC/4mXhzQmAWaxRSPiJtcXNa1s=; b=n2bauAsZLfHS6pBd8YpuWwrHETTvI4/IxHm5dy/0/3+kLO5kUfdvJN0z+D4RINiq57 y5IxfHtbxqXa53x9QDiq5fu3PVFkSMd9PipNoZKzt6fXaXpi3AZB9fXw6FhzpT/3dnGe 30KyQJp1wX0a4rpKwqvYOEPGeirBB1PWFT8Ulm7+qLsjixiUnAtk5SwJnjnJYcx6TM0j lnSOf97CGWWtD4WOUsvt5kYrvFBCQUUlO/HWRX6MDWkI9Wkp3WGha1us/NHVn0kcLq7/ 7kRhl0D+mXjaJlrJv0EYlmFPbwVr/Z6YaTuYTa927FgRcwWhJVEVRmNoGVwPOHiqzbv8 lTow== X-Gm-Message-State: AOAM533U9Rsfvl7vqcgKlgZtVWeoTUhpsp2eKcBM5imZ3i/kyFVlrcrx qCINug69XM/oZulw7eV0N7hF124azXia6tp8eIdkod+67LFYdw== X-Google-Smtp-Source: ABdhPJz4FnK8xOKt2OBy8aaHoasFuvE+hfDVNIZf5+7QgE32a5IL9Dd49lgUJ0mlqzaqd5baiqQDEhorg4lnaA9P9po= X-Received: by 2002:a05:6e02:f06:: with SMTP id x6mr1075751ilj.254.1597983113603; Thu, 20 Aug 2020 21:11:53 -0700 (PDT) MIME-Version: 1.0 References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <9d816729-32b8-488e-90be-06dd8510a370@dogfood.fastmail.com> <48f667c1-d25d-2983-72b5-336a6f800294@network-heretics.com> <25b91252-14a1-2267-06eb-293779df0be6@network-heretics.com> <869d2af1-c20f-9653-62f8-b369d135d29f@gmail.com> In-Reply-To: <869d2af1-c20f-9653-62f8-b369d135d29f@gmail.com> From: Rob Sayre Date: Thu, 20 Aug 2020 21:11:42 -0700 Message-ID: To: Brian E Carpenter Cc: Keith Moore , gendispatch@ietf.org Content-Type: multipart/alternative; boundary="000000000000d7f11e05ad5b6f57" Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Fri, 21 Aug 2020 04:11:56 -0000 --000000000000d7f11e05ad5b6f57 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 20, 2020 at 3:22 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > I have to invoke one of the first things we all learned in CS: Any problem > can be solved by an extra level of indirection. And its corollary: After > some time, the problem will come back, one level down. In other words, > whatever vehicle you use for discussing IETF-wide issues will end up in the > same state: some discussions either get out of hand, or upset some people, > or both. > > Let's not just drive this problem elsewhere. Fix what's wrong with the SAA > mechanism. Keith's message would be a good basis for an I-D. > I don't think the draft really focuses on enforcement. It just points out that it's difficult to be successful in that role, since the charter of the list is not precise enough. To anyone: What's wrong with the 9 changes the draft recommends? thanks, Rob --000000000000d7f11e05ad5b6f57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Aug 20, 2020 at 3:22 PM Brian E C= arpenter <brian.e.carpent= er@gmail.com> wrote:

I have to invoke one of the first things we all learned in CS: Any problem = can be solved by an extra level of indirection. And its corollary: After so= me time, the problem will come back, one level down. In other words, whatev= er vehicle you use for discussing IETF-wide issues will end up in the same = state: some discussions either get out of hand, or upset some people, or bo= th.

Let's not just drive this problem elsewhere. Fix what's wrong with = the SAA mechanism. Keith's message would be a good basis for an I-D.

I don't think the draft really focuse= s on enforcement. It just points out that it's difficult to be successf= ul in that role, since the charter of the list is not precise enough.
=

To anyone: What's wrong with the 9 changes the draf= t recommends?

thanks,
Rob

=
--000000000000d7f11e05ad5b6f57-- From nobody Fri Aug 21 06:40:05 2020 Return-Path: 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 2DCDA3A0992 for ; Fri, 21 Aug 2020 06:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 mPTakCtFesRC for ; Fri, 21 Aug 2020 06:39:59 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42CB3A097C for ; Fri, 21 Aug 2020 06:39:59 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id D1825C53 for ; Fri, 21 Aug 2020 09:39:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 21 Aug 2020 09:39:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=fm3; bh=73MDGn k4Ronj2YtKkh1AeErb396pvGFDsfmoedhLWkk=; b=HdFH2FZfeJyywmcsRDaXr0 5xUOLnbTMGmq34l8Hn3VDEQeIVDNynkyUYdsQJWae2rT9orgnXQeRBbbcspn50F9 qbJ9JOQFVObgh0ALJqyeUufZZaXqbO7ya3tJzKkhOVhUEYYP3obIMXlGxmBREhGD 4xVWvD8dyU9LLdQId6unHcqrLpVxgZtpZQKBClXR/r1AXlqMMSFE3C5HyGcj855T TrvwZ/trBDt1+HeqDoKM42XgEYnVEKsFXbKpemhu0ZNvRe1/FSfEqOKLsz3xOyHU AjGWYsgPWGHnwEBs3XxKhAFPLozkKCjoCrE0/INO1w8GLU2CH2vuUHGQ3+tFeucA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudduvddgiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtre ertdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepveefteduieegtd elvddvtddufeejjeffvdefteejieeulefgtdfggedtffektedunecukfhppedutdekrddv vddurddukedtrdduheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id B8AE53280063 for ; Fri, 21 Aug 2020 09:39:57 -0400 (EDT) To: gendispatch@ietf.org References: <159762600034.21012.3531565855695172680@ietfa.amsl.com> <48D4FA55-C03F-47D8-B91C-4D14A99829B7@mnot.net> <0BD00993-D007-48E3-ABAE-157CCF0CE2C3@akamai.com> <20200818164957.GA86346@straasha.imrryr.org> <090f2c01-6494-7be3-4b99-280576733f35@huitema.net> <7B731DC9-5CB6-4D5B-A382-1E3179D39A9F@mnot.net> From: Keith Moore Message-ID: <4dbbea63-02da-031e-fd24-5f8e2a836bef@network-heretics.com> Date: Fri, 21 Aug 2020 09:39:56 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------650A3F6273352A89204E62A9" Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] I-D Action: draft-nottingham-discussion-recharter-00.txt X-BeenThere: gendispatch@ietf.org 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: Fri, 21 Aug 2020 13:40:04 -0000 This is a multi-part message in MIME format. --------------650A3F6273352A89204E62A9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/20/20 8:32 PM, Mark Nottingham wrote: > > My reading of the situation is that there are a few somewhat conflicting purposes for the ietf@ list, and that blocks any meaningful progress. > > Many see the IETF list as having a plenary function; it is where the organisation comes together to discuss matters of import to everyone. The IESG can get a sense of the community there, participants can hold them to account and raise new ideas, and so on. > > As Christian and others have pointed out, a plenary function needs rules of order for even mildly contentious discussions; otherwise, the loudest can drown out other voices, arguments become circular, and everything becomes generally unproductive. > > Some people also see the IETF list as a Speakers' Corner; the priority is on everyone being able to express themselves. The boundaries of acceptable discourse are therefore broad; it's OK to send a message dripping with sarcasm, ascribing motives to others, meandering about conspiracy theories, and so on. It's also OK in this view to respond to such messages with disdain, etc. -- which brings what one could call 'robust discourse' or 'endless ratholing' depending on your disposition. Perhaps I misunderstand but this doesn't sound like a good analogy to me.   It seems to me that the only situations in which there is a purpose to a Speakers' Corner, is if people are generally /not/ free to speak elsewhere, or cannot find an audience anywhere else.   In IETF there is generally more freedom to speak on other mailing lists than on the ietf@ list.    A Speakers' Corner lets people blow off steam but also marginalizes the speakers by the very fact that they feel the need to choose such a venue.   A physical Speakers' Corner might be a prominent location, but there's no assurance of a large audience.    The ietf@ list presumably does have a large audience relative to the set of IETF participants.   I've never personally heard any IETF participant argue that the ietf@ list should be a place where people are free to speak on any topic, and the set of topics explicitly permitted in RFC 3005 is fairly narrow. So I suspect many more people want the ietf@ list to serve the plenary function, among other things, than for it to serve as a Speakers' Corner. That said, the ietf@ list sometimes has served as a venue of last resort, by participants who have tried to air their concerns on more narrowly-targeted lists and been unhappy with the results. I believe that's an essential function (as long as there's some sense to what the speakers are saying), but to me that isn't the same function as a Speakers' Corner. > These functions are in obvious conflict. > > Of course, some plenaries do serve both functions -- e.g., most legislatures allow a member to speak about whatever is on their mind. However, they always impose limits on that right; e.g., members' speeches only happen at certain times, can only be of a certain length, and there are still ethical requirements that, if violated, can be punished. > > On the IETF list, we don't have effective limits; one can post on any given topic ad nauseam, and as we've seen recently imposing order is tricky (the SAA has been given very blunt tools. I won't defend the recent attempt to use them, but I do sympathise with their position). Traffic volume can definitely discourage participation even when the topic is well within scope and the discourse is civil.   The SAAs might have a role to play in keeping volume to a manageable level, as they do in keeping discussion civil and within scope. > I speculate that this is because while some people see the IETF list as a Speakers' Corner, others see it through the lens of a modern workplace, where behaviour suitable to a Speakers' Corner would often be seen as unprofessional at a minimum, and cause for dismissal in some cases. I suspect that some believe they shouldn't be subjected to unprofessional behaviour as part of their job; beyond just 'standards professionals', _any_ developer that comes to engage with IETF technology is also potentially exposed to such unprofessional behaviour, and may avoid some parts of the organisation or the whole of it as a result. While the Speakers' Corner analogy seems dubious to me, I suspect the "workplace" analogy is apt - particularly for people who are at IETF because they're paid to be there rather than because they have a strong interest in the work.   But I believe there are some ideas that are commonly associated with "professional behavior" that are actually harmful to IETF - especially the notion, common in many workplaces, that there is no room for disagreement with technical decisions issued from on high.   This is probably the biggest reason that I dislike the use of the word "professional" and its derivatives when trying to set bounds on IETF discourse. For IETF it is absolutely essential that participants be free to respectfully disagree with one another, and even (especially) with community leaders.   Any notion of consensus that doesn't result from an open discussion is dubious at best. (We need to let leaders do their jobs but that doesn't mean that they can't be challenged when they misuse or exceed their authority.    ADs are supposed to be able to have technical opinions but it's not wrong to respectfully disagree with them. etc.) Beyond notions of professionalism, I suspect that an broader reason for some participants' discomfort (particularly newcomers) is that IETF doesn't expect or enforce a notion of social hierarchy like they're accustomed to.   Different societies have somewhat different ideas about what defines such a hierarchy. But it's common worldwide for humans feel an obligation to defer to other humans, for reasons that may not be explicit or examined.   Some people will find it disturbing when their peers fail to adhere to those imagined obligations, especially if they're not reprimanded for doing so.   I've seen it happen elsewhere that participants in a technical discussion can become very uncomfortable, even distressed, when their notions of "pecking order" were violated by others, even if the supposedly higher status person being challenged explicitly said its ok. /This discomfort exists even when nobody is using insults or ridicule or hostile "tone"; the mere fact of disagreement with a person of supposedly higher"status" will disrespectful to some participants./ In IETF we need to act as peers as much as practicable.    But the expectation of a pecking order is so common in human society that it's hardly surprising if newcomers feel uncomfortable when they're suddenly expected to function in an environment which, of necessity, has essentially no pecking order. Keith --------------650A3F6273352A89204E62A9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/20/20 8:32 PM, Mark Nottingham wrote:


My reading of the situation is that there are a few somewhat conflicting purposes for the ietf@ list, and that blocks any meaningful progress.

Many see the IETF list as having a plenary function; it is where the organisation comes together to discuss matters of import to everyone. The IESG can get a sense of the community there, participants can hold them to account and raise new ideas, and so on.

As Christian and others have pointed out, a plenary function needs rules of order for even mildly contentious discussions; otherwise, the loudest can drown out other voices, arguments become circular, and everything becomes generally unproductive.

Some people also see the IETF list as a Speakers' Corner; the priority is on everyone being able to express themselves. The boundaries of acceptable discourse are therefore broad; it's OK to send a message dripping with sarcasm, ascribing motives to others, meandering about conspiracy theories, and so on. It's also OK in this view to respond to such messages with disdain, etc. -- which brings what one could call 'robust discourse' or 'endless ratholing' depending on your disposition.

Perhaps I misunderstand but this doesn't sound like a good analogy to me.   It seems to me that the only situations in which there is a purpose to a Speakers' Corner, is if people are generally not free to speak elsewhere, or cannot find an audience anywhere else.   In IETF there is generally more freedom to speak on other mailing lists than on the ietf@ list.    A Speakers' Corner lets people blow off steam but also marginalizes the speakers by the very fact that they feel the need to choose such a venue.   A physical Speakers' Corner might be a prominent location, but there's no assurance of a large audience.    The ietf@ list presumably does have a large audience relative to the set of IETF participants.   I've never personally heard any IETF participant argue that the ietf@ list should be a place where people are free to speak on any topic, and the set of topics explicitly permitted in RFC 3005 is fairly narrow.

So I suspect many more people want the ietf@ list to serve the plenary function, among other things, than for it to serve as a Speakers' Corner.

That said, the ietf@ list sometimes has served as a venue of last resort, by participants who have tried to air their concerns on more narrowly-targeted lists and been unhappy with the results.   I believe that's an essential function (as long as there's some sense to what the speakers are saying), but to me that isn't the same function as a Speakers' Corner. 

These functions are in obvious conflict. 

Of course, some plenaries do serve both functions -- e.g., most legislatures allow a member to speak about whatever is on their mind. However, they always impose limits on that right; e.g., members' speeches only happen at certain times, can only be of a certain length, and there are still ethical requirements that, if violated, can be punished.

On the IETF list, we don't have effective limits; one can post on any given topic ad nauseam, and as we've seen recently imposing order is tricky (the SAA has been given very blunt tools. I won't defend the recent attempt to use them, but I do sympathise with their position).

Traffic volume can definitely discourage participation even when the topic is well within scope and the discourse is civil.   The SAAs might have a role to play in keeping volume to a manageable level, as they do in keeping discussion civil and within scope. 

I speculate that this is because while some people see the IETF list as a Speakers' Corner, others see it through the lens of a modern workplace, where behaviour suitable to a Speakers' Corner would often be seen as unprofessional at a minimum, and cause for dismissal in some cases. I suspect that some believe they shouldn't be subjected to unprofessional behaviour as part of their job; beyond just 'standards professionals', _any_ developer that comes to engage with IETF technology is also potentially exposed to such unprofessional behaviour, and may avoid some parts of the organisation or the whole of it as a result.

While the Speakers' Corner analogy seems dubious to me, I suspect the "workplace" analogy is apt - particularly for people who are at IETF because they're paid to be there rather than because they have a strong interest in the work.   But I believe there are some ideas that are commonly associated with "professional behavior" that are actually harmful to IETF - especially the notion, common in many workplaces, that there is no room for disagreement with technical decisions issued from on high.   This is probably the biggest reason that I dislike the use of the word "professional" and its derivatives when trying to set bounds on IETF discourse.   For IETF it is absolutely essential that participants be free to respectfully disagree with one another, and even (especially) with community leaders.   Any notion of consensus that doesn't result from an open discussion is dubious at best.

(We need to let leaders do their jobs but that doesn't mean that they can't be challenged when they misuse or exceed their authority.    ADs are supposed to be able to have technical opinions but it's not wrong to respectfully disagree with them.   etc.)

Beyond notions of professionalism, I suspect that an broader reason for some participants' discomfort (particularly newcomers) is that IETF doesn't expect or enforce a notion of social hierarchy like they're accustomed to.   Different societies have somewhat different ideas about what defines such a hierarchy.   But it's common worldwide for humans feel an obligation to defer to other humans, for reasons that may not be explicit or examined.   Some people will find it disturbing when their peers fail to adhere to those imagined obligations, especially if they're not reprimanded for doing so.   I've seen it happen elsewhere that participants in a technical discussion can become very uncomfortable, even distressed, when their notions of "pecking order" were violated by others, even if the supposedly higher status person being challenged explicitly said its ok.   This discomfort exists even when nobody is using insults or ridicule or hostile "tone"; the mere fact of disagreement with a person of supposedly higher"status" will disrespectful to some participants.

In IETF we need to act as peers as much as practicable.    But the expectation of a pecking order is so common in human society that it's hardly surprising if newcomers feel uncomfortable when they're suddenly expected to function in an environment which, of necessity, has essentially no pecking order.

Keith


--------------650A3F6273352A89204E62A9-- From nobody Sun Aug 23 03:06:52 2020 Return-Path: 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 08F2F3A0844 for ; Sun, 23 Aug 2020 03:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 uAQ1HLqoE7gJ for ; Sun, 23 Aug 2020 03:06:49 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C89F3A0842 for ; Sun, 23 Aug 2020 03:06:49 -0700 (PDT) Received: (qmail 73470 invoked by uid 100); 23 Aug 2020 10:00:07 -0000 Date: 23 Aug 2020 09:59:43 -0000 Message-ID: <20200823095943.73444.qmail@submit.iecc.com> From: "John Levine" To: gendispatch@ietf.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Gendispatch] Messages from the gendispatch list for the week ending Sun Aug 23 06:00:06 2020 X-BeenThere: gendispatch@ietf.org 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: Sun, 23 Aug 2020 10:06:51 -0000 9 | 59947 | Rob Sayre 6 | 65985 | Keith Moore 6 | 64241 | Mark Nottingham 4 | 36819 | Salz, Rich 4 | 33507 | Dan Harkins 4 | 30685 | Joel M. Halpern 3 | 17317 | Brian E Carpenter 2 | 32665 | Colin Perkins 2 | 16809 | Kyle Rose 2 | 11549 | Pete Resnick 2 | 10292 | Mirja Kuehlewind 2 | 3617 | IESG Secretary 1 | 20764 | Stephen Farrell 1 | 14891 | Bron Gondwana 1 | 13037 | Mary Barnes 1 | 13009 | Christian Huitema 1 | 6449 | Nico Williams 1 | 3326 | Viktor Dukhovni From nobody Sun Aug 23 23:00:10 2020 Return-Path: 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 05FD43A0A4F for ; Sun, 23 Aug 2020 23:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=lowentropy.net header.b=VaGelz1s; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BGLDE2F/ 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 83Qc-sF-v3nl for ; Sun, 23 Aug 2020 23:00:02 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7363A0A4D for ; Sun, 23 Aug 2020 23:00:01 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id E0EAE66D for ; Mon, 24 Aug 2020 01:59:59 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute2.internal (MEProxy); Mon, 24 Aug 2020 02:00:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=2GZjoyFeQ0blvLZq/MejsdPKeH2xh5H 9NjrnMarl5BI=; b=VaGelz1shANot5+W4ddWxG4B5g7H+HM7gpS++Ohk/3gg9ur VyzniW6N5DSM7/TMh9ONk/4XiCf9p7b8IqQ46cRuGb1FrnEUxl7WBipWRajpgG0V wy88HcuFRfSeGAuOiAuGUKdJCU5hgMFIy47p7pLLBNCxOAzyUW4+drhvjTAvEYX6 m+rkuf7Jkcc6LPDe+/cqHD36q4mjdzLBFAUjb65UjZQj0Uh+TAE9JX1hqyOpD0NS plZ7nLe1/y6IM9tej84XcbpcnPs7hWTRcVDiz43fW5Z9Lda83hO5BR1w4AhQ8mlR NYx2EY7geS3jyqT2g8+/RpjcpfbNslc6kskZTcA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=fm3; bh=2GZjoy FeQ0blvLZq/MejsdPKeH2xh5H9NjrnMarl5BI=; b=BGLDE2F/eMpAo2kXEg7dUt 4rJS2koS3mpmjK5JcftJxtHZWFW8r+TmJqKLrrT5z/rnskim0Fv/dxIOpFlixQo4 p2szvpnob68w9JV6dJ2MSaamE2otS9C5T4ArOpRC34lvgjg92w3v7dJ3fDqg9xdb NJCdTCfINBmow2QkPTndxuN0fpZ6NlIJuMrK28FtMMz+1wcGYfouCOXIgxqXLfZx mN7QIhW99HECwwEp4OxcD2ZH3T/wCNVpz/e4VnFvtUoghEyvai1AGJMTw00A9NvX rB1VSD059l8wWzH5w/W1u99+Xvh1nDDcXnk9AlFpFXmhXDcnFP4r9WGBXWn4JNEA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddujedgkedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeelfedugfelgeeigfeuve eludejjeeutdelgedvteehueevhfdvhefggeeuffeivdenucffohhmrghinhepihgvthhf rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3A18B20070; Mon, 24 Aug 2020 01:59:59 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-214-g5a29d88-fm-20200818.002-g5a29d882 Mime-Version: 1.0 Message-Id: <828f3dac-5885-46d6-b938-ddb833567e4b@www.fastmail.com> In-Reply-To: <20200823095943.73444.qmail@submit.iecc.com> References: <20200823095943.73444.qmail@submit.iecc.com> Date: Mon, 24 Aug 2020 15:59:39 +1000 From: "Martin Thomson" To: gendispatch@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Gendispatch] =?utf-8?q?Messages_from_the_gendispatch_list_for_t?= =?utf-8?q?he_week_ending_Sun_Aug_23_06=3A00=3A06_2020?= X-BeenThere: gendispatch@ietf.org 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: Mon, 24 Aug 2020 06:00:07 -0000 Hi John, Should we interpret this as commentary on Mark's draft? I think that this is not a constructive feature of ietf@. I would prefer that it not be replicated here. On Sun, Aug 23, 2020, at 19:59, John Levine wrote: > 9 | 59947 | Rob Sayre > 6 | 65985 | Keith Moore > 6 | 64241 | Mark Nottingham > 4 | 36819 | Salz, Rich > 4 | 33507 | Dan Harkins > 4 | 30685 | Joel M. Halpern > 3 | 17317 | Brian E Carpenter > 2 | 32665 | Colin Perkins > 2 | 16809 | Kyle Rose > 2 | 11549 | Pete Resnick > 2 | 10292 | Mirja Kuehlewind > 2 | 3617 | IESG Secretary > 1 | 20764 | Stephen Farrell > 1 | 14891 | Bron Gondwana > 1 | 13037 | Mary Barnes > 1 | 13009 | Christian Huitema > 1 | 6449 | Nico Williams > 1 | 3326 | Viktor Dukhovni > > -- > Gendispatch mailing list > Gendispatch@ietf.org > https://www.ietf.org/mailman/listinfo/gendispatch > From nobody Sun Aug 23 23:44:37 2020 Return-Path: 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 6A1F33A077A for ; Sun, 23 Aug 2020 23:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5SEcFI_66PTR for ; Sun, 23 Aug 2020 23:44:34 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564723A0766 for ; Sun, 23 Aug 2020 23:44:34 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id s2so7560592ioo.2 for ; Sun, 23 Aug 2020 23:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=ZCej8eTudMkakP2ekMI9gIyx09RcAghBDDDzJzUOxZY=; b=ceISi/9JLf9LWtmfBLCTm/GOVQSDrIXlnNkxwZAeS88LdR0rI/NPMq4uJFqPxbuCtv 7+CjCbHFFwgnSZEQ2IZ8JdJVsXUiujkedlQfH9yjloR5Ry6oCHWxo9mxDBXPQAXccmUj yTCFu0mcj+xSZjAf2mm5wMJi5x/dCoj6GkdtIvNgUJj3O4RrOuBt5eDcP0MWZ3VnYzon uiyZzY20VWv+x3iSxiQhHNjWyST1i3A+sRx2fza7HLm+PvgX2BLE8BYZLil98jHntfHp 5pC3U67NIQXxZGizW1Kiifr4Klu0LvauSj/AuprVGZv13tUXs+HjoacM/06/QSE2hLO0 1a5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ZCej8eTudMkakP2ekMI9gIyx09RcAghBDDDzJzUOxZY=; b=NPiJ0iwO4D1ZvOunpEz/cxcwdsnsjqf8DKCuxcdSwXgZXC4uIQWxk0BGg3T0FCYUf+ OEh3xDVutcqANU+gjoitNKBXIviHlJM7360JMROXhA7/EcjfHRlU5lOt/4ji24WOOeh4 hVy0Meb1fH6mSrRiO1213OqTCCczZwvFmRfFeP2opjk6LfQBYCZ2EJMNhMGkG+Yvhcra 3InXFin4N+6H6ICN8CBbvICcXLncc6HP3FxmVoqtDVIWgjdIC3xlH53mAyqqtcFkRl7l tOfh763uVhX7wJAPw4AsrrrrTb5Z5dYFGk75kNMcwpPbwF4PXjPiAyyloqxP+U2qIOcJ ZJXA== X-Gm-Message-State: AOAM531pTcXDHZGhKuCxNUSpu3j2/f10l0CtPxn0We3qkdCZTFpEXJPs HVwviNNgkIMPwMpycnGVTEhXWtAwyXOCoKtWwGUIOmCbomOkKw== X-Google-Smtp-Source: ABdhPJzLpLHl78ge6r9IEMBI3lfyeRJLh8YYgWCa97Xu6x6s+y2UpTGOPNSrfIfwKBpgMiahoHdK7ZOrBqLkQkctZrg= X-Received: by 2002:a02:3f16:: with SMTP id d22mr4260459jaa.30.1598251473092; Sun, 23 Aug 2020 23:44:33 -0700 (PDT) MIME-Version: 1.0 From: Rob Sayre Date: Sun, 23 Aug 2020 23:44:19 -0700 Message-ID: To: gendispatch@ietf.org Content-Type: multipart/alternative; boundary="00000000000050c4f005ad99eb18" Archived-At: Subject: [Gendispatch] Calculating Traffic X-BeenThere: gendispatch@ietf.org 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: Mon, 24 Aug 2020 06:44:35 -0000 --00000000000050c4f005ad99eb18 Content-Type: text/plain; charset="UTF-8" Hi, What would be the best way to estimate a mailing list participant's byte count? I think it would be best to clip the headers and such, but maybe others have studied this problem more closely. I haven't seen any recent efforts along these lines. thanks, Rob --00000000000050c4f005ad99eb18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

What would be the best way to estim= ate a mailing list participant's byte count? I think it would be best t= o clip the headers and such, but maybe others have studied this problem mor= e closely.

I haven't seen any recent efforts a= long these lines.

thanks,
Rob
--00000000000050c4f005ad99eb18-- From nobody Sun Aug 23 23:48:45 2020 Return-Path: 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 31A9A3A0ABD for ; Sun, 23 Aug 2020 23:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.948, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 zwQ016WLsYhm for ; Sun, 23 Aug 2020 23:48:42 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0A0D3A052C for ; Sun, 23 Aug 2020 23:48:42 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QFK1E87A2X6VG@wwwlocal.goatley.com> for gendispatch@ietf.org; Mon, 24 Aug 2020 01:48:42 -0500 (CDT) Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QFK00H6M2VFQJ@trixy.bergandi.net> for gendispatch@ietf.org; Sun, 23 Aug 2020 23:47:40 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Sun, 23 Aug 2020 23:47:40 -0700 Date: Sun, 23 Aug 2020 23:48:40 -0700 From: Dan Harkins In-reply-to: To: Rob Sayre , gendispatch@ietf.org Message-id: <124a39a9-13c9-9f66-00ca-4ef55dadf26b@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local) References: X-PMAS-Software: PreciseMail V3.3 [200820] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [Gendispatch] Calculating Traffic X-BeenThere: gendispatch@ietf.org 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: Mon, 24 Aug 2020 06:48:44 -0000 On 8/23/20 11:44 PM, Rob Sayre wrote: > Hi, > > What would be the best way to estimate a mailing list participant's > byte count? I think it would be best to clip the headers and such, but > maybe others have studied this problem more closely. > > I haven't seen any recent efforts along these lines.   Probably because it's pointless.   Dan. From nobody Mon Aug 24 00:57:25 2020 Return-Path: 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 55A9E3A0B59 for ; Mon, 24 Aug 2020 00:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.147 X-Spam-Level: X-Spam-Status: No, score=-1.147 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Na6xrXZMppd1 for ; Mon, 24 Aug 2020 00:57:23 -0700 (PDT) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224A23A0B5A for ; Mon, 24 Aug 2020 00:57:23 -0700 (PDT) Received: by mail-pl1-x62f.google.com with SMTP id bh1so3824346plb.12 for ; Mon, 24 Aug 2020 00:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=2lytjGjR7zoXgBlUKtfRYVVtaRGvNXtT4hjmGy4HFWQ=; b=dD4L+HxUg0S2IlYR2avrA8SFNCBjrb+3gTT7jSg9PE9keGmMPY4EEGzEl8Y/rDsOGJ VeGYbf1qMNjckH/sRTySUjknc8LScqcE+IDTuyXDQE5+5sMTCMjwDZRbfiS1dWU7jfya u+HPlKxGEsjzKlTLmKFaTfXpNQPt9zxowgQ6e9KVp1vfeu3qewHH5jj1Io7lwMhxDpja Qz1mJYAGDlQVZ03b1vQINmNVfqfCl7x/E/SGmy1Q95OOC2ztgTupw1YTcP6zYr5EOjCA P5o/FJGMQiDj1qX5I26Wb3Rq54yL4VrtK7moZWdHTvS/HsvS1VLYP040x4g2y8gMTN+j 22Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2lytjGjR7zoXgBlUKtfRYVVtaRGvNXtT4hjmGy4HFWQ=; b=NjIz6DjaZMsApGqmdn1IEgMvbHPdPR5EGgaOEBzHBiiYo9spbGy5WR2d5MV8cz62JA 7puhMA6pd0O1gVEzMG9k71br9tnH82xNV9R9YaNaDYSszzuiPTv24gWCD8VDKB9P1KQU ScfWrQkoEkBZyT2ltnQDHjOaW4afFTjsTawNf5INKNJtPZw4mQ5vpcsTvh/fnAnF3STD D+sOo/bQ4kpOWXqCx/LFiWWxt+ZgUWDRa2bhOZJzLCy+ECDYIm2dP/dWmPnFZiso9nZK gC8ScSX44oJD5XsOOM8QG45uksjNHne6WZxepcTvYU0VaL4qq38zGiUKckXwYCKTZ/Py nu2Q== X-Gm-Message-State: AOAM530soeRPbZKAlReKbwPkd/FXLsw9PQbf7PQjXNjYKPTneHu6ApPQ uvFSim4kREJvHanIASOI6xAndtv/XJeLgA== X-Google-Smtp-Source: ABdhPJzozaOB/wauv/KLVd8THzjpQsfyvTJbLD/dDQEO776wZcXzKk/7Qlo2r8HabracQwKpXLb0UQ== X-Received: by 2002:a17:90a:fb4a:: with SMTP id iq10mr3675031pjb.90.1598255842295; Mon, 24 Aug 2020 00:57:22 -0700 (PDT) Received: from [192.168.178.25] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id v6sm2867685pgf.55.2020.08.24.00.57.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Aug 2020 00:57:21 -0700 (PDT) To: Martin Thomson , gendispatch@ietf.org References: <20200823095943.73444.qmail@submit.iecc.com> <828f3dac-5885-46d6-b938-ddb833567e4b@www.fastmail.com> From: Brian E Carpenter Message-ID: <61871a7e-25d2-1938-14c2-639da1edbcbf@gmail.com> Date: Mon, 24 Aug 2020 19:57:17 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <828f3dac-5885-46d6-b938-ddb833567e4b@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Gendispatch] Messages from the gendispatch list for the week ending Sun Aug 23 06:00:06 2020 X-BeenThere: gendispatch@ietf.org 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: Mon, 24 Aug 2020 07:57:24 -0000 On 24-Aug-20 17:59, Martin Thomson wrote: > Hi John, > > Should we interpret this as commentary on Mark's draft? > > I think that this is not a constructive feature of ietf@. Why not? It was originally introduced to act as a mild negative feedback on unduly prolific posters, with no intention to influence quality, just quantity. I found it helpful as a way to judge my own contribution to the noise level. > I would prefer that it not be replicated here. I agree that we don't seem to have a problem on this list at present. Brian From nobody Mon Aug 24 06:50:15 2020 Return-Path: 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 5C9D43A0E08 for ; Mon, 24 Aug 2020 06:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 IC-KqVdV-XSL for ; Mon, 24 Aug 2020 06:50:12 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9583A0E0D for ; Mon, 24 Aug 2020 06:50:12 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 96E515C0112 for ; Mon, 24 Aug 2020 09:50:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 24 Aug 2020 09:50:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=9mFeM5tqGd6jHD2pkCchIG5I9tOHPmOgHQdgcB3wm T4=; b=olV0MRS8F88zRLIZKSf7MFeZ9urcZjx9MoB+ai08TrMFRmNKy4vn9W3gd VnwBtctLPlFxQhxMVVH0KvLm1sGoJEd88zzU3gbqGglVFzsjW+qkrP+YlUGPZBPY Kxp/1Tjk/QUJWWVBLqZO4K+JtfPMYHEkexnCGUjOijhXvI+jOmYsI9H+XwYAd7Wf MY4cCKSbUw/TCXMgApraZRFPSsdrpbslYA226u1sNV/ywPYwYw/VPSwY113mte0r GdgOhUKarMOw2kutD6Y1L7BhKif8NJvAdAzo/9dpiTxBBc2vZPoMVvPiaTB2P7W6 k8kc4Y3V64NuWQSy1+LK27eMIHu1Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddukedgfeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtje ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeekvdeggfelue elkeeuhfffheeghffhkeeuvdduudeihfehudefffdtgfdtkeffgfenucfkphepuddtkedr vddvuddrudektddrudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 2B12030600B7 for ; Mon, 24 Aug 2020 09:50:11 -0400 (EDT) To: gendispatch@ietf.org References: <20200823095943.73444.qmail@submit.iecc.com> <828f3dac-5885-46d6-b938-ddb833567e4b@www.fastmail.com> From: Keith Moore Message-ID: <3f136fc7-4a03-b616-5574-ba91c31169e3@network-heretics.com> Date: Mon, 24 Aug 2020 09:50:09 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <828f3dac-5885-46d6-b938-ddb833567e4b@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] Messages from the gendispatch list for the week ending Sun Aug 23 06:00:06 2020 X-BeenThere: gendispatch@ietf.org 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: Mon, 24 Aug 2020 13:50:13 -0000 On 8/24/20 1:59 AM, Martin Thomson wrote: > I think that this is not a constructive feature of ietf@. I would prefer that it not be replicated here. +1. From nobody Mon Aug 24 08:00:55 2020 Return-Path: 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 3F2A43A0ECF for ; Mon, 24 Aug 2020 08:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=akamai.com 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 M79SrqBBdHs8 for ; Mon, 24 Aug 2020 08:00:53 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21B4B3A086D for ; Mon, 24 Aug 2020 08:00:52 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07OExQft020272 for ; Mon, 24 Aug 2020 16:00:52 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=05W2Zje5x/1xE4f+0JvYwSs8crQgSl+QeYE9SnNm6Cg=; b=hwJ3YhxEH1Bp9n20Gc2a+KJD/ii1YegzP6G/XNd7x8CCiLZFDRPvqmrGS6CfYT7gypXE I+CujJzhC632YaOhQocrsMjCGfzg6Xbqlab2V1VpplBM/cIxhASvAyu7IySqx167Tqc6 tBbsZnpZP8tK8mCeLbUURtgicI3llr56+2pYDg8t9I9jzTw+mh48qRLSHnaPWQSXJsDx Galdzm+Z4RfgvIXJT5obNrw5ExQlO7lPZvZ0Mvh8V+pjRMqt141sneyz932KKgw34NcU BSnCDKncapXxZ+B9z6HyYmPCimJfYro/YhgxizD/+/M6/hG1Gg9mK5D+h6Oc1tVUchsM sg== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 332r818ujy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 24 Aug 2020 16:00:52 +0100 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 07OEZSWd022947 for ; Mon, 24 Aug 2020 11:00:51 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint6.akamai.com with ESMTP id 332xpxvuk9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 24 Aug 2020 11:00:51 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 24 Aug 2020 11:00:50 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1497.006; Mon, 24 Aug 2020 11:00:50 -0400 From: "Salz, Rich" To: "gendispatch@ietf.org" Thread-Topic: [Gendispatch] Messages from the gendispatch list for the week ending Sun Aug 23 06:00:06 2020 Thread-Index: AQHWedvWFICJhhW1zki7fjbYBDOV7qlHWvyA Date: Mon, 24 Aug 2020 15:00:49 +0000 Message-ID: References: <20200823095943.73444.qmail@submit.iecc.com> <828f3dac-5885-46d6-b938-ddb833567e4b@www.fastmail.com> In-Reply-To: <828f3dac-5885-46d6-b938-ddb833567e4b@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.21] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-24_12:2020-08-24, 2020-08-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 mlxlogscore=671 adultscore=0 phishscore=0 bulkscore=0 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008240117 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-24_12:2020-08-24, 2020-08-24 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=605 phishscore=0 impostorscore=0 priorityscore=1501 lowpriorityscore=0 malwarescore=0 suspectscore=0 bulkscore=0 spamscore=0 adultscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008240121 Archived-At: Subject: Re: [Gendispatch] Messages from the gendispatch list for the week ending Sun Aug 23 06:00:06 2020 X-BeenThere: gendispatch@ietf.org 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: Mon, 24 Aug 2020 15:00:54 -0000 PiAgICBJIHRoaW5rIHRoYXQgdGhpcyBpcyBub3QgYSBjb25zdHJ1Y3RpdmUgZmVhdHVyZSBvZiBp ZXRmQC4gIEkgd291bGQgcHJlZmVyIHRoYXQgaXQgbm90IGJlIHJlcGxpY2F0ZWQgaGVyZS4NCg0K SSBhbHNvIHByZWZlciBpdCB0byBub3QgYmUgcmVwbGljYXRlZC4gIFRoZSBtYWpvciBkaWZmZXJl bmNlIGlzIHRoYXQgKnRoaXMqIGxpc3QgaGFzIGEgc3BlY2lmaWMgY2hhcnRlciwgYW5kIFdHIGNo YWlycyB0byBlbmZvcmNlIGl0Lg0KIA0KDQo= From nobody Mon Aug 24 08:21:12 2020 Return-Path: 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 82F923A0F33 for ; Mon, 24 Aug 2020 08:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Ke3yhgxXkxdi for ; Mon, 24 Aug 2020 08:21:09 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E2B3A0F8C for ; Mon, 24 Aug 2020 08:21:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 83B79B9E0C15; Mon, 24 Aug 2020 10:21:04 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0yJH2irIqrV; Mon, 24 Aug 2020 10:21:03 -0500 (CDT) Received: from [172.16.1.6] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id AE816B9E0C0C; Mon, 24 Aug 2020 10:21:02 -0500 (CDT) From: "Pete Resnick" To: "John Levine" Cc: gendispatch@ietf.org Date: Mon, 24 Aug 2020 10:21:02 -0500 X-Mailer: MailMate (1.13.1r5706) Message-ID: <8E151008-AFE1-4C30-AF5C-F766C7493E6C@episteme.net> In-Reply-To: <20200823095943.73444.qmail@submit.iecc.com> References: <20200823095943.73444.qmail@submit.iecc.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: Re: [Gendispatch] Messages from the gendispatch list for the week ending Sun Aug 23 06:00:06 2020 X-BeenThere: gendispatch@ietf.org 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: Mon, 24 Aug 2020 15:21:11 -0000 Independent of whether it's a good thing for the IETF list, it was not requested here AFAIK, and I would prefer if it not be sent to this list at this time. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Mon Aug 24 08:51:56 2020 Return-Path: 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 18ECE3A0F61 for ; Mon, 24 Aug 2020 08:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 2FY1-h-GiFaW for ; Mon, 24 Aug 2020 08:51:53 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36E9E3A0C94 for ; Mon, 24 Aug 2020 08:51:53 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0E90C5C0100 for ; Mon, 24 Aug 2020 11:51:52 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 24 Aug 2020 11:51:52 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=8BjvVb WdexQ+wMa9191dAN3IOTGsEli6XTPp6AwrKkY=; b=VqiYxJQDXOMToSfE6F6amU qYRo9LJ2LhrQfVpB21YpvHZWRTF6NljZFzb44MtdVl+r3T12G+4BEgD1UgkJE4Se q1dh1PPCdmEvt+kpz5ERHzuSnwyfxsbrcC13392NnP9AliwxaJNHUkVnzZJjNzm0 dPyxdhkuizHI0OCaaqsH/OF976nhyns/YJwMYL/hUqkjeI/kxTBoKp8+brdiqZTh yme97g1GZRi9yzfvCyf4/wseIpNEbQqbwJNsjSN0fUiSFKOmqkUNP4QH3r9ydzJX nLpqGBS73T4xIM+z6eGXWEozbieoLzPCIsGC1ZWVZDayUEb+nWD3DMxutvaVPkCg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddukedggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefvhffukffffgggtgfgsehtkeertd dtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthifohhr khdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeetfeevhedufeelvd eikeefjedtvdehhfejhfdtheehfedvtdelgeeugfefuedtueenucfkphepuddtkedrvddv uddrudektddrudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 8C53630600A6 for ; Mon, 24 Aug 2020 11:51:51 -0400 (EDT) To: gendispatch@ietf.org From: Keith Moore Message-ID: Date: Mon, 24 Aug 2020 11:51:49 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Gendispatch] is there some way to provide feed-forward to the gendispatch meeting? X-BeenThere: gendispatch@ietf.org 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: Mon, 24 Aug 2020 15:51:55 -0000 I have been working on a set of suggestions for, hopefully, how to resolve the conflict surrounding how to avoid use of exclusionary language. But because this is an unusual working group and an unusual kind of meeting, I'm not sure how to proceed. Should I submit an I-D, or slide deck?  Or would an email suffice?   Or something else? thanks, Keith From nobody Mon Aug 24 09:41:50 2020 Return-Path: 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 04A343A1109; Mon, 24 Aug 2020 09:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 yxyOyfNmbnaN; Mon, 24 Aug 2020 09:41:46 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60086.outbound.protection.outlook.com [40.107.6.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4EC3A10FB; Mon, 24 Aug 2020 09:41:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dRPgOVKfUXxzaqzJFWMncbmBwEwRZ1CMN9HF4lU62Ff/Hua3usHFaw/rTbGEhRII0NkMyhwC5AZ3xS/0H0tFqG8hI7LgChHuVvawFrQmBzMpJtAVG5yxw03022nzJtzgGBqTdCq/jW6YkBHVLqr6whAMXSJVaNRXzp9krapyrlYbiuGFm6jsBKJx7SFNq316LOGyXtS0vtA4TFzysmWhnhz6WoyAsYXqgnLr5x2owbYZFfjVVI/qVHcQY0EJETF3WL+Kq5/M3wQC4ITRZ6DIffe1ufcx7AidqBORhheQFlGt2jo7c8G3Gu5WHbYF8IjyKgG/atR9qq6tg+psmuCaoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ul1xxmUbYqPnctMD0yQRkbEWq7gOt1id0hp0Mukpbp4=; b=JQNAsRSIcPkfNV7Nn3pPYo3nXt8JIAECLT501J86q40BA65KqDNEKTjL5DO30feH2iE+PazN+wuwufV+zvxp4fzuh3h+FETuqnZGMDe98VOmsQO7Y0cFLwXlJX8/IHzSXpLvxuQGihxMtwkug/SeE7fIoFKNOE18yTEtMD2pMd++o6kftHoxgxfeYzVTPMHyhN8N1sewmlgGq2Zq7+X//zLYmA/e52PyeOXfjpnqwW1MMpkAjSsy9rnTYlwSAwbEjwusZWjaEyBEW7m1NkAJxQmEV2F3lOoFNdjXuwNV7yXk/p0Rbru4tDvDyUY3EYK0V5CCuwWHREK2t5MN47yvAA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ul1xxmUbYqPnctMD0yQRkbEWq7gOt1id0hp0Mukpbp4=; b=fxxwsbH5LA/vCFxxDeXh41S6EDdNCCGqTaLgYaUIJtH+Tyxr+axDXu0IzbZWe+s81YlL0w139RLJadjq+YIoIzUNMYsv4sF2WOLI+t+ZjpTJUw7A5C17sswka6Si8dJcIdmjqLf3tD4rN9Pns7V5nI8X7506FlXY0gzA7G5YuBc= Received: from VI1PR07MB4477.eurprd07.prod.outlook.com (2603:10a6:803:74::33) by VI1PR07MB3120.eurprd07.prod.outlook.com (2603:10a6:802:24::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.10; Mon, 24 Aug 2020 16:41:42 +0000 Received: from VI1PR07MB4477.eurprd07.prod.outlook.com ([fe80::cba:ac03:353c:2d1f]) by VI1PR07MB4477.eurprd07.prod.outlook.com ([fe80::cba:ac03:353c:2d1f%7]) with mapi id 15.20.3326.017; Mon, 24 Aug 2020 16:41:42 +0000 From: Francesca Palombini To: Keith Moore , "gendispatch@ietf.org" CC: "gendispatch-chairs@ietf.org" Thread-Topic: [Gendispatch] is there some way to provide feed-forward to the gendispatch meeting? Thread-Index: AQHWei6HH72olkHYFUCE42AKW/g6eqlHmA2A Date: Mon, 24 Aug 2020 16:41:41 +0000 Message-ID: <296717BF-1039-4CA8-BBE0-B3399A6605E2@ericsson.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: network-heretics.com; dkim=none (message not signed) header.d=none;network-heretics.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 29a93a54-f052-4528-7ba7-08d8484c94ad x-ms-traffictypediagnostic: VI1PR07MB3120: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qrWZ6RJbnSVx8GlnXjTIyU0zor4Ffpn29wGorKtggy8afF0lbnCFvMY6CPFJmXlz6fQTWjglPQIqU5RFFaQCkPi/TgrOwpBvSi4eiRxavS5KCdZRybwezXIGo2nro4b9nuLJGfpDLW4gjAXfz0VFcd4C+2FKcDf0h3UUdkUd3G4CMaDpr/HEV7rwSR0GeGwhX8oUbVurbOqS5xQSVssaKXHsVcbR39a240qvUMfpGy06xFHiRg+l6VQNFxuiYnaHehdhMpuKUIYwDil9MM3wyOkeMbt4a/PwHAkEK+lZ0Qxev7xBYG725OMn+H5wMzNMsT2IADoq9bPev4N9KX8jVX6aFKbg9gChhrP5qszje+60F+a/D2YoQNmfk5fTJ3+wlPsygB1zC0/YFBQvqDkFAH7fG0lLXZMexEEnfDBY1vceyZXwLx5soycgKCYmoG16ERnvs1I3dzHPz0AvTqysew== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB4477.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(376002)(39860400002)(136003)(346002)(2906002)(8936002)(66946007)(6512007)(66446008)(36756003)(66556008)(71200400001)(91956017)(478600001)(76116006)(8676002)(66476007)(110136005)(64756008)(86362001)(966005)(316002)(4744005)(26005)(6506007)(6486002)(2616005)(186003)(83380400001)(4326008)(5660300002)(44832011)(33656002)(43043002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: YkJXQWFkw7KnQP7mzAu0hjvC/thVQ5Z9c1ID2tYupIuwMKpIyaYr07/pXY0g+pFLRS22aX1VX30FGXmrJ3DFMv5Dk2IluFV8gzyD5jgQGbGHCh8vnHRqJNblusbgCTRzWfwHBtzJC0UZAuuR9E//BHfdybfz4ZJ+2axke8RnLZmr9jABbRChvUbMDvgET6TDhIDGsrrVo1Xy/KgpRtGewZATPQjC+4ZpFPgVj5npqgQKCnPWCZH9liZbj2KtK90Nj0TO5aG/UO/G8PRY4rlnvUP2vTV0qL4eaN+sNeLFQmJeW/0QBJ9gpY3C8gsWw/wizesKBp1zs+rvkd+GxzQYKvPu7gWeeghmK4slncf5dMKItM8qXpuotVdsTcFrIGx3n32tb62mIiOEj7+LU+5xRmKkPcg8Ts3wMnBxexyShLiyoYK0X2pjLHxGScagwE7B7CLQ46cMAyEuBZ8Cz1lkBnity6bbzA2J0WHKxOwwDSLvcTaSo/vEPAYS032XQL3zEHuGhKtJ9EYh1uzamTbg/TOkDvKhuCuxg94/hcSoipfqfEyG89dU9Y3GqJ9JWDXteGb4WNDbV8zJLXt2gGrWCRkGgVFB79T1RcFlWalxVyKY8EIdyt9/2YthSAFDvbvyQoqYHM2mEMY9ymOfK/9l2A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB4477.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 29a93a54-f052-4528-7ba7-08d8484c94ad X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2020 16:41:42.0457 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4P+JiYS+nSKwenDmxiFahL+/I4z8nfkJ3IUXxu6nu5P9dv47G9GxibA+DgllryTenyPp9wPB6LM5eNMj2sXBgafVelAKkrjeq6YttgbsI76I9CQZAOprgcNfQGvfIKPc X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3120 Archived-At: Subject: Re: [Gendispatch] is there some way to provide feed-forward to the gendispatch meeting? X-BeenThere: gendispatch@ietf.org 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: Mon, 24 Aug 2020 16:41:48 -0000 SGkgS2VpdGgsDQoNClBsZWFzZSBzdWJtaXQgYSBkcmFmdCBhcyBzb29uIGFzIHBvc3NpYmxlIChp ZGVhbGx5IHRvZGF5IG9yIHRvbW9ycm93KSB0byBnaXZlIHBlb3BsZSB0aGUgdGltZSB0byByZWFk IGl0IGJlZm9yZSB0aGUgaW50ZXJpbSwgYW5kIHRoZW4gcG9zdCBpdCB0byB0aGUgbWFpbGluZyBs aXN0Lg0KDQpUaGFua3MsDQpGcmFuY2VzY2ENCg0K77u/T24gMjQvMDgvMjAyMCwgMTc6NTIsICJH ZW5kaXNwYXRjaCBvbiBiZWhhbGYgb2YgS2VpdGggTW9vcmUiIDxnZW5kaXNwYXRjaC1ib3VuY2Vz QGlldGYub3JnIG9uIGJlaGFsZiBvZiBtb29yZUBuZXR3b3JrLWhlcmV0aWNzLmNvbT4gd3JvdGU6 DQoNCiAgICBJIGhhdmUgYmVlbiB3b3JraW5nIG9uIGEgc2V0IG9mIHN1Z2dlc3Rpb25zIGZvciwg aG9wZWZ1bGx5LCBob3cgdG8gDQogICAgcmVzb2x2ZSB0aGUgY29uZmxpY3Qgc3Vycm91bmRpbmcg aG93IHRvIGF2b2lkIHVzZSBvZiBleGNsdXNpb25hcnkgbGFuZ3VhZ2UuDQoNCiAgICBCdXQgYmVj YXVzZSB0aGlzIGlzIGFuIHVudXN1YWwgd29ya2luZyBncm91cCBhbmQgYW4gdW51c3VhbCBraW5k IG9mIA0KICAgIG1lZXRpbmcsIEknbSBub3Qgc3VyZSBob3cgdG8gcHJvY2VlZC4NCg0KICAgIFNo b3VsZCBJIHN1Ym1pdCBhbiBJLUQsIG9yIHNsaWRlIGRlY2s/ICBPciB3b3VsZCBhbiBlbWFpbCBz dWZmaWNlPyAgIE9yIA0KICAgIHNvbWV0aGluZyBlbHNlPw0KDQogICAgdGhhbmtzLA0KDQogICAg S2VpdGgNCg0KDQogICAgLS0gDQogICAgR2VuZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQogICAgR2Vu ZGlzcGF0Y2hAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2dlbmRpc3BhdGNoDQoNCg== From nobody Mon Aug 24 10:18:25 2020 Return-Path: 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 3FE923A11F7 for ; Mon, 24 Aug 2020 10:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=XoNxB58e; dkim=pass (2048-bit key) header.d=taugh.com header.b=EK9IEeeT 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 bkOMkjbEcCWC for ; Mon, 24 Aug 2020 10:18:20 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1246A3A1150 for ; Mon, 24 Aug 2020 10:18:19 -0700 (PDT) Received: (qmail 6696 invoked from network); 24 Aug 2020 17:18:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1a26.5f43f659.k2008; bh=QcnIEfNjmHvnjKo2SjzPgfpuxlbyOosAx/GkiKO4WVY=; b=XoNxB58ekpMHmJDPsK+DRQyYycDdZc978DCYdU3ivScI15b/MKCyRjFIpsM+Y590qeHW3gWvD32BTskAID2XRtMewIB4oM1rHUikcNf++1Ly/ISgpqWwV9JEQKqzpF6URLiVuTgt4AGDb2v0dH74xGh2DNRzrtQozn/W9BZ9uOY1z2zpMpFvD8cYFWpFME8ttgY/dAUA8O02TRdHTujK8ftMgo3KIMB8QJF4lHIKulh3w7jo3mJKMHBQCp71t1n4NIfNI+RYS2Fb7UlRJ/ZdsuTjVDo5y9yGeSyQUVFrS9UquJRWmtImC3tlqfburAzrVmJkylQPOByBda37omfZkQ== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=1a26.5f43f659.k2008; bh=QcnIEfNjmHvnjKo2SjzPgfpuxlbyOosAx/GkiKO4WVY=; b=EK9IEeeT7dXU/zsYRboGsLdQe51Y9/A1IEznEXkY8jd9RQ3wYU3PVrjh28+zHZGUU0VCdwQapzmKyoNTjT44KQWuPbSkCDyfZ9eTKKUk+TMtB8z3iWBNfm663J9Jo3BlsrBz8hTEKpFWzi68LyVUfDeLoD4Z5qp9xbcKVJzdiokMVth24+JuxnbLtJKSWdHPV/M1jffhY0XpootJCjA+GjPLeoazpu1qWYv2/nDxyrXcJr0nDDodTmxoj3Ngr4bfvIZDXADuYkODqbSqLTP6z3RsGsbpi1/riseKJK1Nzb2wZOHxjs2bKpQt+FCHamzJJ6OkymViGyyVYOooTlbE0Q== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 24 Aug 2020 17:18:17 -0000 Received: by ary.qy (Postfix, from userid 501) id 372C21F14B69; Mon, 24 Aug 2020 13:18:17 -0400 (EDT) Date: 24 Aug 2020 13:18:17 -0400 Message-Id: <20200824171817.372C21F14B69@ary.qy> From: "John Levine" To: gendispatch@ietf.org Cc: rsalz@akamai.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Gendispatch] Messages from the gendispatch list for the week ending Sun Aug 23 06:00:06 2020 X-BeenThere: gendispatch@ietf.org 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: Mon, 24 Aug 2020 17:18:22 -0000 In article you write: >> I think that this is not a constructive feature of ietf@. I would prefer that it not be replicated here. > >I also prefer it to not be replicated. The major difference is that *this* list has a specific charter, and WG chairs to enforce it. OK, I took this list out of the script. From nobody Tue Aug 25 04:40:51 2020 Return-Path: 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 4C18E3A0C63 for ; Tue, 25 Aug 2020 04:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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=s6974d4M; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EeCviZW/ 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 3Y7KN76u3Hom for ; Tue, 25 Aug 2020 04:40:48 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5290B3A0C67 for ; Tue, 25 Aug 2020 04:40:48 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 84F0B5C0070 for ; Tue, 25 Aug 2020 07:40:47 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 25 Aug 2020 07:40:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:date:from:to:subject :content-type; s=fm3; bh=aokXUBdORwzHeb9wC9NVtQdBrVF75MXZbcvSq6X V/bA=; b=s6974d4MVV1RLog5g+JDmedN5WG8ZLhZRCHzu6g1i30KOskTehn6949 DYYT4RnCsF/RjtnJROY+PoE48w+1mSO0o2+Y6tzN0+Cr4w836Vs/IggVYjTmRlzu N6/c75Ytmx3COw7XhCDAjo9KnKHoj+YMJfhUOvGs8MGsfvl6F4vAMyyNzBymTG15 qRkSKngTS4uv7hjGMajSW9dHQCxwB86N/qpia0zQElR6LwJT96paM68jRq75dbMm FX8cJxPoGUJFRsY3AAtucGQbQdjAB0DIK7LsqKAkD95+7basUiVPsQMr7bSTmhFh kb16paV64MKzzjCszH2TXWxUb6vS6KQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=aokXUBdORwzHeb9wC9NVtQdBrVF75 MXZbcvSq6XV/bA=; b=EeCviZW/J9A4CEEj0EWlQuGh5gjP1sYsba6WOzU1OFjJY zW4/X/hCgjs56f5Ih0AF0XlxSYYXviumqGitqPXadH5b+ujXjHAkUcYx6G4HlryH whcRV713BA1Gf1E0yQRRGEHeWLbuLkDn7arKKoQcyur08qj57X+1OGegbTBdaxw0 qXRSDzJFBqsolsCtsdepNIVq5LCSDa2H1x0UciocRIKLKg5CYChNiQ7qWBPG27P1 7rOQ7RfQUf5rcbSRR5g0iZmvxYKhiH7x2H54CIC7h5BcDHvWpcHBaANvLFk7FzKJ 8touNQEpjw295vP5LGTS32vU3psKQjmfSrDRA+PAw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddggeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsegrtderre erreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghesfhgr shhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedtleefgeduteethf ehgedtleevhfduudfhieejgeehtdeviedttdeugfegvdejheenucffohhmrghinhepihgv thhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EECB91804B0; Tue, 25 Aug 2020 07:40:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-225-gd87cabf-fm-20200825.001-gd87cabfd Mime-Version: 1.0 x-forwarded-message-id: <159835524640.18000.16148339994277914759@ietfa.amsl.com> Message-Id: Date: Tue, 25 Aug 2020 21:40:22 +1000 From: "Bron Gondwana" To: gendispatch@ietf.org Content-Type: multipart/alternative; boundary=920967913f5e4826ae33632f90099509 Archived-At: Subject: [Gendispatch] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draf?= =?utf-8?q?t-gondwana-effective-terminology-01=2Etxt?= X-BeenThere: gendispatch@ietf.org 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: Tue, 25 Aug 2020 11:40:50 -0000 --920967913f5e4826ae33632f90099509 Content-Type: text/plain I did promise that I'd draft something up as an alternative terminology starting point. I've done some revising based on feedback from a couple of people I cross checked this with, but it's definitely nowhere near "done". My key goals are: * make sure we celebrate the good work that the IETF has done and continues to do while talking about ways we could improve * acknowledge the real cost of changing terminology and that there are risks involved, while also making it clear that change is sometimes needed and delaying it makes it more expensive, not less * make the mechanism for filtering unwanted words be author persuasion and review pressure, not a set of outright forbid den words, as that's more scaleable and responsive to the outside world I had a couple of people review this for me privately to make sure I wasn't doing something totally insane here, thanks to them for the pointers. I posted -00 as well so everyone can see where I came from - and the github repo also has the original commit. Chairs, I would appreciate some time to talk about this draft at the upcoming interim meetings. Thanks, Bron. ----- Original message ----- From: internet-drafts@ietf.org To: Bron Gondwana Subject: New Version Notification for draft-gondwana-effective-terminology-01.txt Date: Tuesday, August 25, 2020 21:34 A new version of I-D, draft-gondwana-effective-terminology-01.txt has been successfully submitted by Bron Gondwana and posted to the IETF repository. Name: draft-gondwana-effective-terminology Revision: 01 Title: Effective Terminology in IETF drafts Document date: 2020-08-25 Group: Individual Submission Pages: 7 URL: https://www.ietf.org/internet-drafts/draft-gondwana-effective-terminology-01.txt Status: https://datatracker.ietf.org/doc/draft-gondwana-effective-terminology/ Htmlized: https://tools.ietf.org/html/draft-gondwana-effective-terminology-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-gondwana-effective-terminology Diff: https://www.ietf.org/rfcdiff?url2=draft-gondwana-effective-terminology-01 Abstract: The IETF and the RFC series are trusted names, for producing high quality technical documents that make the Internet work better. While the success of our documents is variable, many of them are widely used over a long time period. As norms in the outside world change, our documents need to remain relevant and accessible to future generations of those working on the internet, everywhere in the world. This longevity of our documents, and the impossibility of predicting the future, implies that we should be conservative in the language that we send. Effective language expresses our intent with clarity, and without distraction. This document describes a glossary for increasing awareness of terms which are going to be clear and effective without turning readers away, to enable our mission of making the Internet work better. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --920967913f5e4826ae33632f90099509 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
I did promise that I'd draft something up as an alternativ= e terminology starting point.  I've done some revising based on fee= dback from a couple of people I cross checked this with, but it's defini= tely nowhere near "done".
My key goals are:
* make sure we celebrate the good work tha= t the IETF has done and continues to do while talking about ways we coul= d improve
* acknowledge the r= eal cost of changing terminology and that there are risks involved, whil= e also making it clear that change is sometimes needed and delaying it m= akes it more expensive, not less
= * make the mechanism for filtering unwanted words be author persuasion a= nd review pressure, not a set of outright forbid
den words, as that's more scaleable and responsive t= o the outside world

I had a couple of people review this = for me privately to make sure I wasn't doing something totally insane he= re, thanks to them for the pointers.  I posted -00 as well so every= one can see where I came from - and the github repo also has the origina= l commit.

Chairs, I would appreciate some time to talk about = this draft at the upcoming interim meetings.

Thanks,

Bron.

-= ---- Original message -----
To: = Bron Gondwana <brong@fastma= ilteam.com>
Subject: New Version Notification for d= raft-gondwana-effective-terminology-01.txt
Date: Tuesday, = August 25, 2020 21:34


A new version of I-D, draft-gondwana-effective-termi= nology-01.txt
has been succes= sfully submitted by Bron Gondwana and posted to the
IETF repository.

Name: draft-gondwa= na-effective-terminology
Revi= sion: 01
Title: Effective Te= rminology in IETF drafts
Docu= ment date: 2020-08-25
Group: = Individual Submission
Pages:= 7
Htmlized:     &nb= sp; https://tools.ietf.org/html/draft-gondwana-effective-te= rminology-01
Diff:      = ;     https://www.ietf.org/rfcd= iff?url2=3Ddraft-gondwana-effective-terminology-01

Ab= stract:
   The IETF= and the RFC series are trusted names, for producing high
   quality technical documents th= at make the Internet work better.

   While the = success of our documents is variable, many of them are
   widely used over a long time peri= od.

   As norms in the outside world change, ou= r documents need to remain
&n= bsp;  relevant and accessible to future generations of those workin= g on the
   interne= t, everywhere in the world.
<= br>
   This longevity o= f our documents, and the impossibility of predicting
   the future, implies that we should = be conservative in the language
   that we send.  Effective language expresses our int= ent with clarity,
  = ; and without distraction.
   This document des= cribes a glossary for increasing awareness of terms
   which are going to be clear and effect= ive without turning readers
&= nbsp;  away, to enable our mission of making the Internet work bett= er.

         = ;            = ;            = ;            = ;            = ;            = ;            = ; 


Please = note that it may take a couple of minutes from the time of submission
until the htmlized version and = diff are available at tools.ietf.org.

The IETF Secretaria= t



<= /div>

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


--920967913f5e4826ae33632f90099509-- From nobody Tue Aug 25 06:15:42 2020 Return-Path: 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 296F13A0D07 for ; Tue, 25 Aug 2020 06:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[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 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 EomOVvKozNHk for ; Tue, 25 Aug 2020 06:15:37 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FE6D3A0D08 for ; Tue, 25 Aug 2020 06:15:36 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1kAYnU-0006sy-8u for gendispatch@ietf.org; Tue, 25 Aug 2020 15:15:34 +0200 References: <159836041291.7759.5433299149297755017@ietfa.amsl.com> To: gendispatch@ietf.org From: Niels ten Oever Autocrypt: addr=lists@digitaldissidents.org; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtC1OaWVscyB0ZW4g T2V2ZXIgPGxpc3RzQGRpZ2l0YWxkaXNzaWRlbnRzLm9yZz6JAj8EEwEIACkFAlgvB3YCGyMF CQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRAO2D86RorIs56yD/44BSJvKnjH ex0nhPDI9nIJlzlnypa4qsniy0obG5GRbVRikT1E1xaz7VBoPs39hCywoIWd6p0hs1PG1Tcj WV0GwNKRt90PPEh6iNJSGjV2Aq3IlME/aUViD9008yfbRSqfsnPXLW1kpCoZNaOSNzpURoM9 OkVU/z4LSLD61SfFFByBne/GkJKt96/fcspBif1GPC//63ZKFrDqQ9JFR6dECAmsKv7baayz MTv3wrTcqpuHcqJIv4vTm8IPx1QiGgEvrMwsPZz/vx8bMdxxxHWgCcbrt+0b3tRzq9ATZwG3 xDiwnJgKd+ioZOC/b5sY69721sqwBmWYyXWVqtqt01xIgNZjr/wixam+l1bTGUgj0rwPWJWx +7Whe25ff+mNNW/UQeCBjZlxoxAJWSr1Pp3n+SQKQ4TLs8wIwHZtcVCffepfHd47CEbnR8Kc Tjm3tlKzSWq4zcUy6BaxHfgn9+HaAM7fwLqx9/WAtSfdmLXJTN+Swy0w/slakD75jl2o7U3e ETjoYQWt+306X2Uly/0ge7VEQ4ySmmbru6U5ainGE95gjsc++s+hvKmMuGYL3h4ijE1RSe/k wgM6/Z1B6JosssdX+KRuuk2A4FHGbcee8LUIJ3C36qyI7s6PJBXi6SjIPN0wpx30P/DUf/Lr o5lmHF03qQ5eeqI8lDwIobWlJbkCDQRYKXEdARAAxYOE3/AFmEfQ0SVVFujYFhZKX+BGXolY ytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fxj+uXvLKAm9xQRI/DCug7/NGULMk9 bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHwyIawsSCN9AhDXZQWVRqkR1QXcq3I YKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVOBR8xUCBbyk5aRW4VSGO6pUD3H21u r+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8ITaNdFSAttkdT56wAQpxE2h8zaOmBa FUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZtPP9gIX+ic8QO5iuct37bRXJU/rm rH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJHE8JMaX0yYT6h4PGRS3mNM4bka8hj dfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCVaTfJLFPEru3drxNwi6ogdkRmcLGK qqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+uPlDtuExehLsNOMpjP8qhZpFtyLe DS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwODyVwk3MK5Em4pJ0+IAJx+F6gta0B k2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAKCRAO2D86RorIs0ykD/4t151SZG9M beKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvbgB4CtkBuXQlq+plOBWv+rFEThOzy 3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK83OGnfM02qP1Ky8d7EoZz+nTSMf/ DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9Oy1wWy6fHjwx3r+wQSokBNfxgQyAF onmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDvLwOUYKevBIeJJcqTyfAn3TtJbPCE HOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWvKKmBNBB5OJ/rmHogbNU+wWPJ723q MBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiGpWv4tMc5oB/qVh3my1VO65ErcJ3S 9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJBX6jeYZabGvnTicQlBAzfGpblFqV 3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0OhbnytnopKJKk99bwMoCqDkfQvT3 LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ9DYmtE40zO6g70VVxUj+dKt2hbJT y/KQTb7Ijhw7wZrGp/P7nhbVyA== X-Forwarded-Message-Id: <159836041291.7759.5433299149297755017@ietfa.amsl.com> Message-ID: <7f6de5d6-7f0c-e19d-f9e3-bd85d65b3fdc@digitaldissidents.org> Date: Tue, 25 Aug 2020 15:15:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <159836041291.7759.5433299149297755017@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-As-Hash: 29cc722430e8f1f6ed904119444c0d49b0f3ee91 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 1f72ff50073f138f9668c095d6f579a1 Archived-At: Subject: [Gendispatch] Fwd: New Version Notification for draft-knodel-terminology-04.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 25 Aug 2020 13:15:40 -0000 Dear all, Here is a new version of draft-knodel-terminology for discussion during the interim. I hope we'll have some time to present. This time the document will be presented by Mallory. Best, Niels -------- Forwarded Message -------- Subject: New Version Notification for draft-knodel-terminology-04.txt Date: Tue, 25 Aug 2020 06:00:12 -0700 From: internet-drafts@ietf.org To: Mallory Knodel , Niels ten Oever A new version of I-D, draft-knodel-terminology-04.txt has been successfully submitted by Niels ten Oever and posted to the IETF repository. Name: draft-knodel-terminology Revision: 04 Title: Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs Document date: 2020-08-24 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-knodel-terminology-04.txt Status: https://datatracker.ietf.org/doc/draft-knodel-terminology/ Htmlized: https://tools.ietf.org/html/draft-knodel-terminology-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-knodel-terminology Diff: https://www.ietf.org/rfcdiff?url2=draft-knodel-terminology-04 Abstract: This document argues for more inclusive language conventions sometimes used by RFC authors and the RFC Production Centre in Internet-Drafts that are work in progress, and in new RFCs that may be published in any of the RFC series, in order to foster greater knowledge transfer and improve diversity of participation in the IETF. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Aug 25 12:18:24 2020 Return-Path: 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 923303A08D1 for ; Tue, 25 Aug 2020 12:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.948, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 DhSTcMEFKvrc for ; Tue, 25 Aug 2020 12:18:21 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA3DF3A08CB for ; Tue, 25 Aug 2020 12:18:21 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QFM1M559WALUW@wwwlocal.goatley.com> for gendispatch@ietf.org; Tue, 25 Aug 2020 14:18:21 -0500 (CDT) Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QFM00HJAW8NBJ@trixy.bergandi.net> for gendispatch@ietf.org; Tue, 25 Aug 2020 12:17:12 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Tue, 25 Aug 2020 12:17:12 -0700 Date: Tue, 25 Aug 2020 12:18:18 -0700 From: Dan Harkins In-reply-to: <7f6de5d6-7f0c-e19d-f9e3-bd85d65b3fdc@digitaldissidents.org> To: Niels ten Oever , gendispatch@ietf.org Message-id: <26b35865-6413-23fe-1b33-079b0bb7e27b@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local) References: <159836041291.7759.5433299149297755017@ietfa.amsl.com> <7f6de5d6-7f0c-e19d-f9e3-bd85d65b3fdc@digitaldissidents.org> X-PMAS-Software: PreciseMail V3.3 [200824] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [Gendispatch] Fwd: New Version Notification for draft-knodel-terminology-04.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 25 Aug 2020 19:18:24 -0000 On 8/25/20 6:15 AM, Niels ten Oever wrote: > Dear all, > > Here is a new version of draft-knodel-terminology for discussion during the interim. I hope we'll have some time to present. This time the document will be presented by Mallory.   I see you've removed the unprofessional text that called someone out by name as "an indicator of actual racism." That's good. You might also want to remove the reference in 8.4. But you replaced it with a vague accusation of racism on the part of critics of your draft: "There is harm in protracted discussion about the validity IETF [sic]    participants and their experiences with exclusionary terminology.    The racism in the community that has been surfaced [sic] as a result    of this larger debate among technologists pushed away participants    and observers." That's very offensive. You're attempting to silence critics and avoid having to make your case by smearing people who ask you legitimate questions as racists.   This version might actually be worse than the previous one.   Dan. > Best, > > Niels > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-knodel-terminology-04.txt > Date: Tue, 25 Aug 2020 06:00:12 -0700 > From: internet-drafts@ietf.org > To: Mallory Knodel , Niels ten Oever > > > A new version of I-D, draft-knodel-terminology-04.txt > has been successfully submitted by Niels ten Oever and posted to the > IETF repository. > > Name: draft-knodel-terminology > Revision: 04 > Title: Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs > Document date: 2020-08-24 > Group: Individual Submission > Pages: 12 > URL: https://www.ietf.org/internet-drafts/draft-knodel-terminology-04.txt > Status: https://datatracker.ietf.org/doc/draft-knodel-terminology/ > Htmlized: https://tools.ietf.org/html/draft-knodel-terminology-04 > Htmlized: https://datatracker.ietf.org/doc/html/draft-knodel-terminology > Diff: https://www.ietf.org/rfcdiff?url2=draft-knodel-terminology-04 > > Abstract: > This document argues for more inclusive language conventions > sometimes used by RFC authors and the RFC Production Centre in > Internet-Drafts that are work in progress, and in new RFCs that may > be published in any of the RFC series, in order to foster greater > knowledge transfer and improve diversity of participation in the > IETF. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > From nobody Tue Aug 25 13:23:15 2020 Return-Path: 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 B3D953A0B75 for ; Tue, 25 Aug 2020 13:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.944 X-Spam-Level: X-Spam-Status: No, score=-0.944 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 RB8KI4OkFrAa for ; Tue, 25 Aug 2020 13:23:12 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FCE3A0B60 for ; Tue, 25 Aug 2020 13:23:12 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 88DD45C00A4 for ; Tue, 25 Aug 2020 16:23:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 25 Aug 2020 16:23:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=zUn2C/qBC8Y/uReLvxQza/zU1onu5HbpIrCDDplqc u8=; b=k3sB3CV8IoBDUrHUewH+YY+ncK5y1bYmQekZ1kL0S9kxDIs8sL6sCtWDs V386xVGlZCDqkusCL97w0QnPPbQjfOF5biuxr8utTGVoR7QbyGH+kz94xN/dUwmt B17+AOzxSr/BNkDtSo5YP7XVjVTliTHnc0RDHXMLgk+jOqTUpa0xqfRDmsEiCZlH 2vKGo2r7t4Lu6iGXVwMGK//PkJaMzzL9uzXtssdF1Bb9YGv6X54611uvyBYnnumx ljd86GRVhDNlsAqRzdWDqcQHnercKOeuAMm1KlhyIrIpciKPLElcRl7p2A26bwQN 4rxPPCwzbZ+pHf4wMcfUN0+D9rzFQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvtddgudehudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesth ekredttdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvght fihorhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhephefhuedthe efgfefgffhkeehgfeugfeiudeugeejkeefleelueeiffetfeeuudeunecukfhppedutdek rddvvddurddukedtrdduheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id C1D0330600A9 for ; Tue, 25 Aug 2020 16:23:10 -0400 (EDT) To: gendispatch@ietf.org References: <159836041291.7759.5433299149297755017@ietfa.amsl.com> <7f6de5d6-7f0c-e19d-f9e3-bd85d65b3fdc@digitaldissidents.org> <26b35865-6413-23fe-1b33-079b0bb7e27b@lounge.org> From: Keith Moore Message-ID: <795732e5-263c-c8be-86e7-43e440ae4eea@network-heretics.com> Date: Tue, 25 Aug 2020 16:23:08 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <26b35865-6413-23fe-1b33-079b0bb7e27b@lounge.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] Fwd: New Version Notification for draft-knodel-terminology-04.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 25 Aug 2020 20:23:14 -0000 On 8/25/20 3:18 PM, Dan Harkins wrote: > > "There is harm in protracted discussion about the validity IETF [sic] >    participants and their experiences with exclusionary terminology. >    The racism in the community that has been surfaced [sic] as a result >    of this larger debate among technologists pushed away participants >    and observers." I wonder if such an accusation is permissible under RFC 7154. Keith From nobody Tue Aug 25 13:51:59 2020 Return-Path: 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 E41E43A0BB0 for ; Tue, 25 Aug 2020 13:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.146 X-Spam-Level: X-Spam-Status: No, score=-1.146 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.948, SPF_HELO_NONE=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=gmail.com 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 HSpLroFUDlGT for ; Tue, 25 Aug 2020 13:51:57 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5CE23A0BAD for ; Tue, 25 Aug 2020 13:51:57 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id k18so8272475pfp.7 for ; Tue, 25 Aug 2020 13:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=uVtwH3GuRvHH0U/GChmLV5rRtCQZ7MU6fGo3WwtPVUI=; b=oi5OKYc0H4QLJJXXZSUecqWtI2R6D9tVcrG/R9mvvZaIyzNrnwq+2r6D1QgQARsc6Z YKWvAvvJeCqea99qn36MK1Qk6hAUaghdUugqY9LV66pj8qPDoqf1C71DGWB7hYlPul1Q I3a3sWI7TPNrEq/+BZMwp6rEMFoUHIBSh2boQJTcpGb993bEaxft2JLxvWtJc53gvsfM sfxfBm9XTR885IVIYFYtVYxg8C0Jfb5zlnoMZb16HcFaD/0p6Jqh3QqaX0DnYjxkTIJ5 6EMY+d+Tq4RY+A5d8KR02wxD9Ik3T7V0Z1JzstiePf2aKySPFtzSpyaMBJvrrVwfYnh8 xXYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=uVtwH3GuRvHH0U/GChmLV5rRtCQZ7MU6fGo3WwtPVUI=; b=cJ4X2OgA0wkKhZxH9pVIAl6Tq7i1ar7EVBzqQZgujUeV3qNR3f7iGKb2jFvHtTVDvq JN9BSg5a/fU58RibRTaY3tu+s28gfeYAb+qVG3ZJd36n0Yj9hAsBTFLU6OrF+AHarytL MJtCTw0G56UyHL4S7s/VJl94fE93i1qnLMRyiZ+74rvKQyxnhJ2wnBBWUWGMSx/SltC5 AFUfEsSwENM810dEYH87laZGiW3RL1zIx9Kqj+ghtCFQrWF2Mxeh3e9wGmmqjHz4GJAX qEgUxaOJWFfnFQd/TESVqsDElMMzXUQORhNcSM9KQNR02MsnSlBGCoGwWt8ifKQATeDx Awug== X-Gm-Message-State: AOAM532iVEOeqVKVWg5Id4WdMviIecU9eYJOysgDsKD+ThTH8pea7u3I +Bn2T4S6A0OPPp67uv/Q/8UmAUCAG3to8A== X-Google-Smtp-Source: ABdhPJwkYwihART1IGobsFQ3W/esnRmXZoE51Z/o+pPHMmvbU0IHSkQuBHbJUXhaQ3dzA66CbaTj1w== X-Received: by 2002:a63:547:: with SMTP id 68mr7215618pgf.327.1598388716651; Tue, 25 Aug 2020 13:51:56 -0700 (PDT) Received: from [192.168.178.20] ([151.210.139.192]) by smtp.gmail.com with ESMTPSA id t10sm139318pfq.52.2020.08.25.13.51.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Aug 2020 13:51:55 -0700 (PDT) To: Bron Gondwana , gendispatch@ietf.org References: From: Brian E Carpenter Message-ID: <3a30e4ad-1225-e440-efd9-2bf00339296d@gmail.com> Date: Wed, 26 Aug 2020 08:51:55 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Gendispatch] Fwd: New Version Notification for draft-gondwana-effective-terminology-01.txt X-BeenThere: gendispatch@ietf.org 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: Tue, 25 Aug 2020 20:51:59 -0000 Bron, Thanks for this. I like the tone and the choice of language. Just one rem= ark: > 5. IANA Considerations >=20 > This document does not ask the IANA to do anything (unless we decide= > that IANA is a good place for a central glossary to be kept) I think IANA would be a bad place for that, but my reaction was to identi= fy a missing section: 5a. RFC Editor Considerations This document does not ask the RFC Editor to do anything (unless we de= cide that the RFC Editor site is a good place for a central glossary to be = kept). On the other hand, maybe it isn't useful for us to keep any such glossary= anywhere. Regards Brian On 25-Aug-20 23:40, Bron Gondwana wrote: > I did promise that I'd draft something up as an alternative terminology= starting point.=C2=A0 I've done some revising based on feedback from a c= ouple of people I cross checked this with, but it's definitely nowhere ne= ar "done". >=20 > My key goals are: > * make sure we celebrate the good work that the IETF has done and conti= nues to do while talking about ways we could improve > * acknowledge the real cost of changing terminology and that there are = risks involved, while also making it clear that change is sometimes neede= d and delaying it makes it more expensive, not less > * make the mechanism for filtering unwanted words be author persuasion = and review pressure, not a set of outright forbid > den words, as that's more scaleable and responsive to the outside world= >=20 > I had a couple of people review this for me privately to make sure I wa= sn't doing something totally insane here, thanks to them for the pointers= =2E=C2=A0 I posted -00 as well so everyone can see where I came from - an= d the github repo also has the original commit. >=20 > Chairs, I would appreciate some time to talk about this draft at the up= coming interim meetings. >=20 > Thanks, >=20 > Bron. >=20 > ----- Original message ----- > From:=C2=A0internet-drafts@ietf.org > To: Bron Gondwana > > Subject: New Version Notification for draft-gondwana-effective-terminol= ogy-01.txt > Date: Tuesday, August 25, 2020 21:34 >=20 >=20 > A new version of I-D, draft-gondwana-effective-terminology-01.txt > has been successfully submitted by Bron Gondwana and posted to the > IETF repository. >=20 > Name: draft-gondwana-effective-terminology > Revision: 01 > Title: Effective Terminology in IETF drafts > Document date: 2020-08-25 > Group: Individual Submission > Pages: 7 > URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0https://www.ietf.org/internet-drafts/draft-gondwana-effective-terminol= ogy-01.txt > Status:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://da= tatracker.ietf.org/doc/draft-gondwana-effective-terminology/ > Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://tools.ietf.o= rg/html/draft-gondwana-effective-terminology-01 > Htmlized:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.= ietf.org/doc/html/draft-gondwana-effective-terminology > Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= https://www.ietf.org/rfcdiff?url2=3Ddraft-gondwana-effective-terminology-= 01 >=20 > Abstract: > =C2=A0=C2=A0 The IETF and the RFC series are trusted names, for produci= ng high > =C2=A0=C2=A0 quality technical documents that make the Internet work be= tter. >=20 > =C2=A0=C2=A0 While the success of our documents is variable, many of th= em are > =C2=A0=C2=A0 widely used over a long time period. >=20 > =C2=A0=C2=A0 As norms in the outside world change, our documents need t= o remain > =C2=A0=C2=A0 relevant and accessible to future generations of those wor= king on the > =C2=A0=C2=A0 internet, everywhere in the world. >=20 > =C2=A0=C2=A0 This longevity of our documents, and the impossibility of = predicting > =C2=A0=C2=A0 the future, implies that we should be conservative in the = language > =C2=A0=C2=A0 that we send.=C2=A0 Effective language expresses our inten= t with clarity, > =C2=A0=C2=A0 and without distraction. >=20 > =C2=A0=C2=A0 This document describes a glossary for increasing awarenes= s of terms > =C2=A0=C2=A0 which are going to be clear and effective without turning = readers > =C2=A0=C2=A0 away, to enable our mission of making the Internet work be= tter. >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 > -- > =C2=A0 Bron Gondwana, CEO, Fastmail Pty Ltd > =C2=A0 brong@fastmailteam.com >=20 >=20 >=20 From nobody Tue Aug 25 19:30:00 2020 Return-Path: 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 640503A0BAD for ; Tue, 25 Aug 2020 19:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=tbBa1wWc; dkim=pass (2048-bit key) header.d=taugh.com header.b=EcenSPOz 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 69ARtrprPBWz for ; Tue, 25 Aug 2020 19:29:56 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7CE3A0BA9 for ; Tue, 25 Aug 2020 19:29:55 -0700 (PDT) Received: (qmail 62882 invoked from network); 26 Aug 2020 02:29:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=f59e.5f45c921.k2008; bh=2rOX7sMTimeIBH75Cu13qz8/e2fbqSW75BjoTqS3Sno=; b=tbBa1wWcafY2xK9B+8mcNKYY6ohUURychPUQ80u2ADQfUVgdqdKzrFmT4VWG04ZV4fJxopNO0pPTBrjTEIzhdQFpLhvHxg9NHaWKg88qQp+BXcg4goALZb+phtWGLgtP8yfH+8h91tvANLZxA4odQ+7KzqNvgLkC2KVFQe1WoB02OUt4iTAxSvFb2AiBU5CgsclHxW+thAeQrIqyDKUVR5Hz/nBgRMIGYl9P+VSCmos7snUrDVwAzoDfL4rxAty9/iT+URLCl4CIv2ZweBj8ZukzK6FM1rCDMWVuoLBVaeraSiizHftsz1AO530bo23yt90NLmdtV4AQ3cF6+Y4J5Q== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=f59e.5f45c921.k2008; bh=2rOX7sMTimeIBH75Cu13qz8/e2fbqSW75BjoTqS3Sno=; b=EcenSPOzUwZE1e8SznW3jZWOwSLduhI1gbL3qLbbOCqCvNVyA+xjvZdFKAMfu/ft90afsYOg69rKk2LWktlPjw0oieFXfH5aceh6nG/DfI+a+68ZpFQf5u0g8ihdzcyUB0a7COZ94exB58MgCHSFRpeWRjgcVPS3DGncosNbqImGruYlKTX5a6jAkpqKinepZd9tPpmFc3XILWKgIO2GXOUNXRV++sgeiJrKQUgJYZeI3eINX4QqIVghBZGRe29241wHZTVWfmhC0JuOla+zC+w78y24WIIl2ogFf3dddcU2Ly5tm20fbTCumC/jHy3xRfoE//NSmORSMarVSGIVOQ== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 26 Aug 2020 02:29:52 -0000 Received: by ary.qy (Postfix, from userid 501) id 5FCD61F29491; Tue, 25 Aug 2020 22:29:52 -0400 (EDT) Date: 25 Aug 2020 22:29:52 -0400 Message-Id: <20200826022952.5FCD61F29491@ary.qy> From: "John Levine" To: gendispatch@ietf.org Cc: brong@fastmailteam.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Gendispatch] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draf?= =?utf-8?q?t-gondwana-effective-terminology-01=2Etxt?= X-BeenThere: gendispatch@ietf.org 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: Wed, 26 Aug 2020 02:29:57 -0000 In article you write: >-=-=-=-=-=- > >I did promise that I'd draft something up as an alternative terminology starting point. I've done >some revising based on feedback from a couple of people I cross checked this with, but it's >definitely nowhere near "done". Thanks -- this is a fine piece of work. It lays out the issues using clear language and avoids external appeals to authority (something guarnated to backfire in this crowd.) It speaks to its readers as peers. It's certainly not perfect but it's a big step forward from where we were a few days ago. R's, John PS: Apropos Brian's remarks. we already have an RFC style guide, so that's the natural place to put any advice on terminology. From nobody Tue Aug 25 20:42:56 2020 Return-Path: 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 5B3ED3A0C22 for ; Tue, 25 Aug 2020 20:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.697 X-Spam-Level: X-Spam-Status: No, score=-0.697 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=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=gmail.com 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 JXimqYBJl8Qf for ; Tue, 25 Aug 2020 20:42:52 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A30F03A0C18 for ; Tue, 25 Aug 2020 20:42:52 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id s2so739395ioo.2 for ; Tue, 25 Aug 2020 20:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=RHTfzFSju+0wmhSPUMLHeqm4XtSGO7OuJUYPjxV5riM=; b=X4I98GUfFkeIrod8RV+E+qM03hiMh78gVhVb2/BQR5zBwKKuMR89kTVrc0rZMq0E1/ CWmhtSgnbmBFnqfMjkJNw3l4cNJaKr85NtEN5srS1r/PzBnDyKorpFoDcJ0qL5P+Ukn/ WMXYoaITXklSlJjoFwp4jI29SNgjy+Jb5mvhKFgWlfutRcrq+vyFjOsWEmnVdadRMt2j T+DitZn01DXrb0OuK1mZrD6BY6itWkyBcgLB5zd8VZyJgfkdneoKz6N+Feby2AKzChtp 6Mn69lgi4DwXpoHZotYwnWfWO9oYv26YwvEgjgZmu8+a/Tc5gg2RtQbZ2bpVTdMW84U/ lrzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RHTfzFSju+0wmhSPUMLHeqm4XtSGO7OuJUYPjxV5riM=; b=PzJpOQb7SkYsdth6wChn20jfceEKtAcdbMu1gXzxTWYmBpbwt05hiVZ+iWtI/7P8xD XYfjTLMYGUWx1B2bw4kV0TrBsDJMKRQkvfmJYbV3k1mk6ulA39Hu2jjmmeLP6XC3VCUM jj78QDS0h8sF0p/9jStAMGGz9zvpBvzBdEO6/BITF99SYh5BEe5yQWZsHPYopOILLOC2 yeAr9dtD+7+QOr102Bo8VIuIWn4uGs8Nbghz5vf7ouGB+42HdwbqxuoqjIjJcLRX7sR3 wizs0Pb1ebTuHW4VN28iI4msgD/I53SDFSvaGmwLYvKp2LLkfjPC55NW1NNLfBtu1eH1 ZnfQ== X-Gm-Message-State: AOAM530NoY2LC4Vap1MjRKqlrojhebgRFkTR2n2w0wqqLXM99umJ5BUs qVnS6tM3UOLzT5cTGsrx9fJEYV49po0Rve0eXvJ3CNvXgB/npg== X-Google-Smtp-Source: ABdhPJwisqz9+/PsDKOqSKGShb0obdePNjSRcXrDUi8+j92FwoB+gvqoeig4FQ3ABYcs2Fo4UxUtk7yNViK9M3dlnlI= X-Received: by 2002:a02:3f16:: with SMTP id d22mr13174203jaa.30.1598413371436; Tue, 25 Aug 2020 20:42:51 -0700 (PDT) MIME-Version: 1.0 From: Rob Sayre Date: Tue, 25 Aug 2020 20:42:37 -0700 Message-ID: To: gendispatch@ietf.org Content-Type: multipart/alternative; boundary="00000000000035721905adbf9d4f" Archived-At: Subject: [Gendispatch] Some thoughts on draft-nottingham-discussion-recharter-00 X-BeenThere: gendispatch@ietf.org 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: Wed, 26 Aug 2020 03:42:54 -0000 --00000000000035721905adbf9d4f Content-Type: text/plain; charset="UTF-8" Hi, You may have seen https://tools.ietf.org/html/draft-nottingham-discussion-recharter-00 The draft is best viewed as descriptive, rather than prescriptive. I think the points in the draft are adequate descriptions, so I will just work with them as assumptions. thanks, Rob --00000000000035721905adbf9d4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

You may have seen=C2=A0
<= br>

The draft is best viewed as = descriptive, rather than prescriptive.

I think the= points in the draft are adequate descriptions, so I will just work with th= em as assumptions.

thanks,
Rob

--00000000000035721905adbf9d4f-- From nobody Tue Aug 25 21:02:27 2020 Return-Path: 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 C44003A0C8B for ; Tue, 25 Aug 2020 21:02:25 -0700 (PDT) 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=eXDi/vXX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OQJuqW8v 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 GGFlghOfisKl for ; Tue, 25 Aug 2020 21:02:24 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D0353A0C87 for ; Tue, 25 Aug 2020 21:02:24 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 76F05FA8; Wed, 26 Aug 2020 00:02:23 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 26 Aug 2020 00:02:23 -0400 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:subject:content-type; s=fm3; bh=uVcQj0e aRBnx0voP1ZL1wmie/s7X4Ck62au27QxHZbE=; b=eXDi/vXXjo6dg0VXNJ3QNt+ tK2tbZxF0bHR//g2MBU+n3U0qgDORBJAOv0cuxTxfnxx+jJlagVJbjhflIs9qa+u qBPl4ar4MCdo9/2jc/tT+IwEro7OxXROY5N5m7FZzR6s0ajWR67h8xSmf/XpDmKj l6XKh4kvKjXzln8MroWI+CAUw+1Dm+pxtmL3WviwaH+BvfzQXaDrxXFvZK/bYIp9 obWcBrlLoAfPEXyHsFUdjuhSDIOQZFD9ovuLySb8c9UoHVnm4TZadaMgG2dseNY3 aFDv0ndLBh6gzwE3T5f5rgF7bNlloAVXJo7ZJf0mk3NQGuVUACD1asrMAOQHVew= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=fm3; bh=uVcQj0 eaRBnx0voP1ZL1wmie/s7X4Ck62au27QxHZbE=; b=OQJuqW8vTw5Fdr4jvtQUQM IShFKKFYdVojal21DW3ZEcmukDW6+yPoMXAT8p9zmIwMxn2gxhJ+iK5kSz2SKrt2 L/dGr0zH9m27FGsoS08m7M37wN7c1L8MNVgqxf6qcl48jfFtsQziUlxdbEmeiL/G xmmTbz4eDLo8wA/8oNI2hr88M/nAMLoGfGl4FZplVashac5bRrrZ1vK/I0IAs5WV FWz45Cq5IzTBIzba/Aq0s2QrsKEbYtHwLF2KWt9JnMI1ObIbIc13OJsWEQzNj8Uc XG7l1ru6kCfacL7JC0mvQs2VO3SzBs5CFkUZONpTUbSSQTBzjPuaMB59u7ZWm83g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvuddgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesrgdtreerreerjeenucfhrhhomhepfdeurhho nhcuifhonhgufigrnhgrfdcuoegsrhhonhhgsehfrghsthhmrghilhhtvggrmhdrtghomh eqnecuggftrfgrthhtvghrnheptdehteegfeevteduffevteehfffghefhvdevkeeuhfeh ueetudehgfegieekjeetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CC2D7180304; Wed, 26 Aug 2020 00:02:22 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-232-g4bdb081-fm-20200825.002-g4bdb081a Mime-Version: 1.0 Message-Id: In-Reply-To: <3a30e4ad-1225-e440-efd9-2bf00339296d@gmail.com> References: <3a30e4ad-1225-e440-efd9-2bf00339296d@gmail.com> Date: Wed, 26 Aug 2020 14:02:02 +1000 From: "Bron Gondwana" To: "Brian E Carpenter" , gendispatch@ietf.org Content-Type: multipart/alternative; boundary=3ff1ad5076154a61bcf4c08701f1da39 Archived-At: Subject: Re: [Gendispatch] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draf?= =?utf-8?q?t-gondwana-effective-terminology-01=2Etxt?= X-BeenThere: gendispatch@ietf.org 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: Wed, 26 Aug 2020 04:02:26 -0000 --3ff1ad5076154a61bcf4c08701f1da39 Content-Type: text/plain On Wed, Aug 26, 2020, at 06:51, Brian E Carpenter wrote: > Bron, > > Thanks for this. I like the tone and the choice of language. Just one remark: > > > 5. IANA Considerations > > > > This document does not ask the IANA to do anything (unless we decide > > that IANA is a good place for a central glossary to be kept) > > I think IANA would be a bad place for that, but my reaction was to identify > a missing section: > > 5a. RFC Editor Considerations > > This document does not ask the RFC Editor to do anything (unless we decide > that the RFC Editor site is a good place for a central glossary to be kept). > > On the other hand, maybe it isn't useful for us to keep any such glossary > anywhere. Good point :) I didn't expect that I'd get everything right in the firstsecond draft, so very happy to have feedback. Without a glossary somewhere the document doesn't really do much at all other than defend the status quo and outline that the IETF generally follows terminology norms that are emerging in the wider community rather than forming them, which maybe has some value in itself - but at that point maybe there's no value in the document! Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --3ff1ad5076154a61bcf4c08701f1da39 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Wed, Aug 26, 2020, at 06:51, Brian E Carpenter wro= te:
Bron,
Thanks for this. I like the to= ne and the choice of language. Just one remark:

> 5.&n= bsp; IANA Considerations
>=  
>   = This document does not ask the IANA to do anything (unless we decide
>    that IAN= A is a good place for a central glossary to be kept)

I th= ink IANA would be a bad place for that, but my reaction was to identify<= br>
a missing section:
<= div style=3D"font-family:Arial;">
5a.  RFC Editor Considerations

   Thi= s document does not ask the RFC Editor to do anything (unless we decide<= br>
   that the RFC Edi= tor site is a good place for a central glossary to be kept).

On the other hand, maybe it isn't useful for us to keep any such glo= ssary
anywhere.

Good point :)  I didn't expect that I'd get everythi= ng right in the firstsecond draft, so very happy to have feedback= .

Without a glossary somewhere the document doesn't reall= y do much at all other than defend the status quo and outline that the I= ETF generally follows terminology norms that are emerging in the wider c= ommunity rather than forming them, which maybe has some value in itself = - but at that point maybe there's no value in the document!

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fa= stmail Pty Ltd
  brong@fastmailteam.com


--3ff1ad5076154a61bcf4c08701f1da39-- From nobody Wed Aug 26 01:48:28 2020 Return-Path: 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 BE0273A10BF for ; Wed, 26 Aug 2020 01:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 6QQEkkn7qqhK for ; Wed, 26 Aug 2020 01:48:24 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08E2C3A1055 for ; Wed, 26 Aug 2020 01:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=483; q=dns/txt; s=iport; t=1598431704; x=1599641304; h=from:content-transfer-encoding:mime-version:subject: message-id:date:cc:to; bh=H7NRFIJ9TVSR8E85LYRJY3/C3NMhKl9+4yovMfgHKd4=; b=BjnSe5KxeBolZ/5F+zux9DDzupocEFTKB9/6ey4d6HEwrjfbURnZaJc+ RbM8olOYw+rFuWczTXXQN1nmeiRJ1w8xamJzE0G5leM7fAcByn1DZ3BNl VwB0zwMSlqSS1a/SLaVrxLXhtKW7KqfyPkOWrgFuJHZiwME/18jph11pX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAQCgIUZf/xbLJq1fHQEBAQEJARI?= =?us-ascii?q?BBQUBQIE5BQELAYNtASASjWSkSwsBAQEMAQEvBAEBhEyCOyU3Bg4CAwEBCwE?= =?us-ascii?q?BBQEBAQIBBgRthWiGMzEOgT6DOYJ9sAh0gTSFUoR9gTgBjTyCAIE4HIIYiHq?= =?us-ascii?q?CLQSlUJB5gm2DDJcdAx6CcwGPAI5FrjiDWAIEBgUCFYFqJIFXMxoIGxVlAYI?= =?us-ascii?q?/PRIZDZxoPwNnAgYKAQEDCZEMAQE?= X-IronPort-AV: E=Sophos;i="5.76,355,1592870400"; d="scan'208";a="29068842" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Aug 2020 08:48:19 +0000 Received: from [10.61.196.175] ([10.61.196.175]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 07Q8mJOP031906 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Aug 2020 08:48:19 GMT From: Eliot Lear Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <7D3CF795-AC40-4B2C-AA0F-205DC329E284@cisco.com> Date: Wed, 26 Aug 2020 10:48:19 +0200 Cc: gendispatch@ietf.org To: Bron Gondwana X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.196.175, [10.61.196.175] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Gendispatch] draft-gondwana-effective-terminology-01.txt X-BeenThere: gendispatch@ietf.org 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: Wed, 26 Aug 2020 08:48:26 -0000 Hi Bron, Thank you for your draft. I think it reflects what I hope is a = consensus view that we do not want to needlessly or accidentally offend = or distract the audience. I particularly like Section 3.2, as it allows = us the opportunity to benefit from subject matter experts as they evolve = guidance. I like that no new process is created, and I like that it = relies on the common sense and decency that our authors almost always = have. Very nice! Eliot= From nobody Wed Aug 26 10:15:45 2020 Return-Path: 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 0E6553A182C for ; Wed, 26 Aug 2020 10:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 sHFe3gh6xQMs for ; Wed, 26 Aug 2020 10:15:41 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B264A3A1818 for ; Wed, 26 Aug 2020 10:15:37 -0700 (PDT) Received: from xse181.mail2web.com ([66.113.196.181] helo=xse.mail2web.com) by mx128.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kAz1F-00147T-45 for gendispatch@ietf.org; Wed, 26 Aug 2020 19:15:33 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4BcC5l2yKqz2d6 for ; Wed, 26 Aug 2020 10:09:47 -0700 (PDT) Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kAyvj-0001HA-90 for gendispatch@ietf.org; Wed, 26 Aug 2020 10:09:47 -0700 Received: (qmail 6561 invoked from network); 26 Aug 2020 17:09:46 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.208]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Aug 2020 17:09:46 -0000 To: Bron Gondwana , Brian E Carpenter , gendispatch@ietf.org References: <3a30e4ad-1225-e440-efd9-2bf00339296d@gmail.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <005ff2af-63e0-db55-7dfd-7c95d2f32375@huitema.net> Date: Wed, 26 Aug 2020 10:09:46 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0970EFA05D2C4A357DC94017" Content-Language: en-US X-Originating-IP: 66.113.196.181 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.181/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.181/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0fJi3Ojdyt5h9PLOIGvr3lipSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDtLSXJfCfZOnWpXE1/I0nj9Xt FNSzkMWnDricnMrpFJoG5U8s7Hy75e8I4UcQNJJNQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEkCyqCRM97FQO8waqZwM6Te42Vki7412dpbhrD2d47zbC3VvU djSCswikK/licfX+oIF6uBSWByrPG2Vxuo/vVPllrFEbCkMryfcYCsgMUJObfBQoU3roWy2GH1DY sAiH3gousbgNfxi2R3uFLvZP/HBXvrLBlKCVRjjdPbjQ4HnBNho1Lszw5OO01yYoll8q2UgzFF+j HNSbIoW1Q++Wvj3dKxLhoxcmaInYbR5vlqFg3eKzPG9E5MikC2dVXWcpK172i/E5sOgbaCtBiSIx 1XwCY8vmv+JqOVJamBHfOGVwjn7Xut/lXagsodd5qqODTFiwcpU4fyz75jxpU98RPGiH1Wgh6RAe nBR+licROGbXNqJfz6msVASTB+MD+1/p7GPMfR4JPnPUgCtpcJi9K9XCcjsWpUk6Sz3/G1tX4O7o Oo70iqAlsD2ZyQe0MRcoHVgC4w3et1CuL5lbWzWC+gRRiI4FYjmNWKK4C97xdQjTPpuFqUUQz+mM 8JAD4ECWoxpxO/09NWWLkT1eQTYfixzd1TBXbJNvBC1nKO3+wSObaFRn+p5b2hrhuVCWQsKFqHTT ez0DsCvEI40nRNgSZFFfEoXm0/FPF8PR0w363lkMnj2N8P/nCp7Yggz2VPs9bscqRIE+6nhki2/N vhrDCXR6mMZiP8hyi9JD/oRrQtQcSyQwpbsYuxSOGTH6k0lfJmkP8s1HCfLKOW1F2ohPJ/AFMvX7 q8M4x6bP/gjzw0OgghQYwZVLClIproNi1WM01Bh4x4h9uYrmdPlyGg3lun80sIBTfGesZu6FzlJ8 P6r2OKHH5lr9xXvSM4nM3avg X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Gendispatch] Fwd: New Version Notification for draft-gondwana-effective-terminology-01.txt X-BeenThere: gendispatch@ietf.org 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: Wed, 26 Aug 2020 17:15:44 -0000 This is a multi-part message in MIME format. --------------0970EFA05D2C4A357DC94017 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/25/2020 9:02 PM, Bron Gondwana wrote: > On Wed, Aug 26, 2020, at 06:51, Brian E Carpenter wrote: >> Bron, >> >> Thanks for this. I like the tone and the choice of language. Just one >> remark: >> >> > 5.=C2=A0 IANA Considerations >> >=C2=A0 >> >=C2=A0=C2=A0=C2=A0 This document does not ask the IANA to do anything= (unless we decide >> >=C2=A0=C2=A0=C2=A0 that IANA is a good place for a central glossary t= o be kept) >> >> I think IANA would be a bad place for that, but my reaction was to >> identify >> a missing section: >> >> 5a.=C2=A0 RFC Editor Considerations >> >> =C2=A0=C2=A0 This document does not ask the RFC Editor to do anything = (unless >> we decide >> =C2=A0=C2=A0 that the RFC Editor site is a good place for a central gl= ossary to >> be kept). >> >> On the other hand, maybe it isn't useful for us to keep any such gloss= ary >> anywhere. > > Good point :)=C2=A0 I didn't expect that I'd get everything right in th= e > firstsecond draft, so very happy to have feedback.. > > Without a glossary somewhere the document doesn't really do much at > all other than defend the status quo and outline that the IETF > generally follows terminology norms that are emerging in the wider > community rather than forming them, which maybe has some value in > itself - but at that point maybe there's no value in the document! Quick feedback to Bron: I like the tone of most of your draft, but you can't get away without addressing the specific issues listed by Mallory and Niels, "master-slave" and "white/black list". Also, your security section has a marked departure in tone with a reference to "bad faith actors." We are witnessing a contentious debate in which I don't think participants are acting in "bad faith", rather than say, deeply held convictions. At a minimum, you need to change the tone, but I think you have to actually change the meaning, because that section goes too far. Suppose a reviewer calls out the use of obsolete metaphors in a last call review, pointing out for example the use of "master/slave". Your text as written empowers the WG chair to discard such comments because they "are harder to prove or evaluate than other claims". That's not the outcome that we want. We have a rough consensus to not use such terms in future documents, and WG chairs should not be directed to ignore that consensus. Fighting that consensus would also be a way "to derail the IETF from its mission, and to use the IETF's brand as clout in political battles" -- just a different side of the political battles. -- Christian Huitema --------------0970EFA05D2C4A357DC94017 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 8/25/2020 9:02 PM, Bron Gondwana wrote:
On Wed, Aug 26, 2020, at 06:51, Brian E Carpenter wrote:
Bron,

Thanks for this. I like the tone and the choice of language. Just one remark:

> 5.  IANA Considerations
> 
>    This document does not ask the IANA to do anything (unless we decide
>    that IANA is a good place for a central glossary to be kept)

I think IANA would be a bad place for that, but my reaction was to identify
a missing section:

5a.  RFC Editor Considerations

   This document does not ask the RFC Editor to do anything (unless we decide
   that the RFC Editor site is a good place for a central glossary to be kept).

On the other hand, maybe it isn't useful for us to keep any such glossary
anywhere.

Good point :)  I didn't expect that I'd get everything right in the firstsecond draft, so very happy to have feedback..

Without a glossary somewhere the document doesn't really do much at all other than defend the status quo and outline that the IETF generally follows terminology norms that are emerging in the wider community rather than forming them, which maybe has some value in itself - but at that point maybe there's no value in the document!


Quick feedback to Bron: I like the tone of most of your draft, but you can't get away without addressing the specific issues listed by Mallory and Niels, "master-slave" and "white/black list". Also, your security section has a marked departure in tone with a reference to "bad faith actors." We are witnessing a contentious debate in which I don't think participants are acting in "bad faith", rather than say, deeply held convictions. At a minimum, you need to change the tone, but I think you have to actually change the meaning, because that section goes too far.

Suppose a reviewer calls out the use of obsolete metaphors in a last call review, pointing out for example the use of "master/slave". Your text as written empowers the WG chair to discard such comments because they "are harder to prove or evaluate than other claims". That's not the outcome that we want. We have a rough consensus to not use such terms in future documents, and WG chairs should not be directed to ignore that consensus. Fighting that consensus would also be a way "to derail the IETF from its mission, and to use the IETF's brand as clout in political battles" -- just a different side of the political battles.

-- Christian Huitema

--------------0970EFA05D2C4A357DC94017-- From nobody Wed Aug 26 11:17:58 2020 Return-Path: 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 B7C7F3A195E for ; Wed, 26 Aug 2020 11:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 V2xt67IFDuLB for ; Wed, 26 Aug 2020 11:17:55 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A2F53A195C for ; Wed, 26 Aug 2020 11:17:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id F10D6BA26C5C; Wed, 26 Aug 2020 13:17:50 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsVhtcPLNX_s; Wed, 26 Aug 2020 13:17:47 -0500 (CDT) Received: from [172.16.1.6] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 91C18BA26C4C; Wed, 26 Aug 2020 13:17:47 -0500 (CDT) From: "Pete Resnick" To: "Keith Moore" , "Dan Harkins" Cc: gendispatch@ietf.org Date: Wed, 26 Aug 2020 12:03:28 -0500 X-Mailer: MailMate (1.13.1r5706) Message-ID: <2B9143E0-C521-44E0-A03B-DBE15DBDB490@episteme.net> In-Reply-To: <795732e5-263c-c8be-86e7-43e440ae4eea@network-heretics.com> References: <159836041291.7759.5433299149297755017@ietfa.amsl.com> <7f6de5d6-7f0c-e19d-f9e3-bd85d65b3fdc@digitaldissidents.org> <26b35865-6413-23fe-1b33-079b0bb7e27b@lounge.org> <795732e5-263c-c8be-86e7-43e440ae4eea@network-heretics.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; markup=markdown Archived-At: Subject: [Gendispatch] Dispatching and document content (Was: New Version Notification for draft-knodel-terminology-04.txt X-BeenThere: gendispatch@ietf.org 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: Wed, 26 Aug 2020 18:17:57 -0000 I want to start out by saying that the details of this draft are not terribly relevant to the main dispatch question we're meant to be answering: How should this topic be dispatched? As has been said before, while we need to look at some of the contents to decide if the document is a good starting point for work, we might end up suggesting not to use this document. Bron has proposed a different approach to the same topic area, and Keith has suggested he might do the same. Our primary focus should be on whether the topic area is one that the IETF should be working on, and if so in what form. Going after a specific paragraph in a specific document is not helpful in answering those questions. On the items you've called out, concerns that a document author (or any participant, really) is saying things that are "unprofessional", or "offensive", or "attempting to silence critics", or "smearing people", should really be brought to the chairs of the WG (or, depending on the nature of the comment, bringing it to the Ombudsteam) and not argued on the list. The chairs can then take appropriate action including discussions with the person off-list, a public admonishment, or bringing things to the AD or IESG as appropriate. In particular, having another participant on the list escalate things by publicly accusing the author of saying something "unprofessional", or of making an "accusation of racism on the part of critics", or of "smearing people ... as racists" is not a useful path to solve the problem. Finally: On 25 Aug 2020, at 15:23, Keith Moore wrote: > On 8/25/20 3:18 PM, Dan Harkins wrote: > >> "There is harm in protracted discussion about the validity IETF [sic] >> participants and their experiences with exclusionary terminology. >> The racism in the community that has been surfaced [sic] as a >> result >> of this larger debate among technologists pushed away participants >> and observers." > > I wonder if such an accusation is permissible under RFC 7154. The reference to "racism in the community" I took as a reference to institutional racism, not an accusation of individual bigots in the community. I do not think it is a personal attack. pr -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Wed Aug 26 11:50:16 2020 Return-Path: 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 6CAE03A0808 for ; Wed, 26 Aug 2020 11:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 rzB7AcDzibIm for ; Wed, 26 Aug 2020 11:50:13 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16E33A0803 for ; Wed, 26 Aug 2020 11:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5953; q=dns/txt; s=iport; t=1598467812; x=1599677412; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=ZEDbN6i306MZ4mrm6rCMeJEdoXq6AGMKcyyX4AFXLtU=; b=C5xo7INc1Ew/FXPbpNYCxTPfhptgko9hMEq/25mkkUSbu/H0HdtuvzRF 1nToFTpzdiog7/71jcLxSlKEthzMuCoIgtwnp68kCSKI9X+APQb5bc4MR BkOmZKidq9BWLJEm+J/4lDUTmzIRHB5LeGDa0K0bc/TTefnQQSA+Oi0tn g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BgAAAIrkZf/xbLJq1fHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGBdgcBAQsBgXqBcwEgEoRjiCFgiAwllAOGHIF9CwEBAQwBAS8?= =?us-ascii?q?EAQGETAKCOSU0CQ4CAwEBCwEBBQEBAQIBBgRthWiFcwEEASNUAgULC0ICAlc?= =?us-ascii?q?GgxYCIYJdILE1doEyhVKFAoE4AY0+ggCBOAwQgk0+h1Qzgi0EkkyTCY9xgQi?= =?us-ascii?q?CbYMMlx8DHpF3jkeuOoNYAgQGBQIVgVQ6gVczGggbFTsqAYI/PRIZDY5WbgE?= =?us-ascii?q?IjRs/A2cCBgEJAQEDCZB/AQE?= X-IronPort-AV: E=Sophos; i="5.76,356,1592870400"; d="scan'208,217"; a="29023596" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Aug 2020 18:50:08 +0000 Received: from [10.61.210.152] ([10.61.210.152]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 07QIo7UN004935 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Aug 2020 18:50:08 GMT From: Eliot Lear Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_8C872D5A-7A69-41B9-9057-1B9A9C46BCD4" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 26 Aug 2020 20:50:07 +0200 In-Reply-To: <005ff2af-63e0-db55-7dfd-7c95d2f32375@huitema.net> Cc: Bron Gondwana , Brian E Carpenter , gendispatch@ietf.org To: Christian Huitema References: <3a30e4ad-1225-e440-efd9-2bf00339296d@gmail.com> <005ff2af-63e0-db55-7dfd-7c95d2f32375@huitema.net> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.210.152, [10.61.210.152] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Gendispatch] New Version Notification for draft-gondwana-effective-terminology-01.txt X-BeenThere: gendispatch@ietf.org 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: Wed, 26 Aug 2020 18:50:14 -0000 --Apple-Mail=_8C872D5A-7A69-41B9-9057-1B9A9C46BCD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Christian, > Quick feedback to Bron: I like the tone of most of your draft, but you = can't get away without addressing the specific issues listed by Mallory = and Niels, "master-slave" and "white/black list". It seems to me that Bron is dereferencing to a glossary, not all that = different from what Alissa posted, and then deferring to the working = group, document authors, and the consensus process as to what to do = next. As an author I will tell you, and I am sure you feel the same, = the last thing I want to do in a technical specification is get wrapped = around the axle on terminology that might offend someone. Who here = would stand on their heads with such a thing? The only time would be if = people were being entirely unreasonable in terms of claiming certain = words were offensive, when it was plainly clear they were not. > Also, your security section has a marked departure in tone with a = reference to "bad faith actors." We are witnessing a contentious debate = in which I don't think participants are acting in "bad faith", rather = than say, deeply held convictions. At a minimum, you need to change the = tone, but I think you have to actually change the meaning, because that = section goes too far. > Suppose a reviewer calls out the use of obsolete metaphors in a last = call review, pointing out for example the use of "master/slave". Your = text as written empowers the WG chair to discard such comments because = they "are harder to prove or evaluate than other claims". That's not the = outcome that we want. We have a rough consensus to not use such terms in = future documents, and WG chairs should not be directed to ignore that = consensus. >=20 IMHO I don=E2=80=99t think we have that consensus, and I don=E2=80=99t = think we should try for consensus on specific words or phrases or the = IETF will definitely have departed from its mission to the language = police absent context. Case and point: do you think anyone would ever = create a new use for master/slave, knowing the hell that will come at = them? > Fighting that consensus would also be a way "to derail the IETF from = its mission, and to use the IETF's brand as clout in political battles" = -- just a different side of the political battles. >=20 Not following you. Eliot Eliot= --Apple-Mail=_8C872D5A-7A69-41B9-9057-1B9A9C46BCD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Christian,

Quick feedback to Bron: I like the tone of = most of your draft, but you can't get away without addressing the specific issues listed by Mallory and Niels, "master-slave" and "white/black list".

It seems to me = that Bron is dereferencing to a glossary, not all that different from = what Alissa posted, and then deferring to the working group, document = authors, and the consensus process as to what to do next.  As an = author I will tell you, and I am sure you feel the same, the last thing = I want to do in a technical specification is get wrapped around the axle = on terminology that might offend someone.  Who here would stand on = their heads with such a thing?  The only time would be if people = were being entirely unreasonable in terms of claiming certain words were = offensive, when it was plainly clear they were not.

Also, = your security section has a marked departure in tone with a reference to "bad faith actors." We are witnessing a contentious debate in which I don't think participants are acting in "bad faith", rather than say, deeply held convictions. At a minimum, you need to change the tone, but I think you have to actually change the meaning, because that section goes too = far.

Suppose a = reviewer calls out the use of obsolete metaphors in a last call review, pointing out for example the use of "master/slave". Your text as written empowers the WG chair to discard such comments because they "are harder to prove or evaluate than other claims". That's not the outcome that we want. We have a rough consensus to not use such terms in future documents, and WG chairs should not be directed to ignore that consensus.

IMHO I don=E2=80=99t = think we have that consensus, and I don=E2=80=99t think we should try = for consensus on specific words or phrases or the IETF will definitely = have departed from its mission to the language police absent context. =  Case and point: do you think anyone would ever create a = new use for master/slave, knowing the hell that will come at = them?

Fighting that consensus would = also be a way "to derail the IETF from its mission, and to use the IETF's brand as clout in political battles" -- just a different side of the political battles.


Not following you.

Eliot

Eliot
= --Apple-Mail=_8C872D5A-7A69-41B9-9057-1B9A9C46BCD4-- From nobody Wed Aug 26 12:46:05 2020 Return-Path: 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 244043A0978 for ; Wed, 26 Aug 2020 12:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 3kuSIo4vPOid for ; Wed, 26 Aug 2020 12:45:56 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E76153A0AA3 for ; Wed, 26 Aug 2020 12:45:55 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 51ADA158D for ; Wed, 26 Aug 2020 15:45:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 26 Aug 2020 15:45:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=mEogiZxQqzQckARkwYq9FRp9RrCKvL4bii/gFRMvi K4=; b=MvDN1BfbGn45khKYaJbZJ20XuzWboQtYDDAdOwA8+ewO5IkTfDGpfRQl/ LcpfmbXHksigjRtiXQdvYGnHzDJ1qIIVmpmcod384H8FgBAY2ibkH3t7BUdk8VdJ lzzdq7mht93ayyMKRz9Rj9eFYuH0V7gePLsUSz5IePXfVp1UL3AXpaBaNskOx6jQ c+4/Rerj2C8tjlvTVnSQ3k4NCEjEAEIRm87r1Stqxw2TUpcyPaKP5YfhkopWmk6x CeWyk9cL1AZ03cDtFyAJwvziEdkU3Jkx2A6/xvGpCYAtL3pTarz9hrUpss2KC+L8 iHbngnzeVJmwXU9/hWxnLkh2ZAlMQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvvddgudeflecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesth ejredttdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvght fihorhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepkedvgefgle euleekuefhffehgefhhfekuedvudduiefhhedufefftdfgtdekfffgnecukfhppedutdek rddvvddurddukedtrdduheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 463B9306005F for ; Wed, 26 Aug 2020 15:45:54 -0400 (EDT) To: gendispatch@ietf.org References: <3a30e4ad-1225-e440-efd9-2bf00339296d@gmail.com> <005ff2af-63e0-db55-7dfd-7c95d2f32375@huitema.net> From: Keith Moore Message-ID: <6bae0b4b-0124-2578-16ef-b06494161990@network-heretics.com> Date: Wed, 26 Aug 2020 15:45:52 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <005ff2af-63e0-db55-7dfd-7c95d2f32375@huitema.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] Fwd: New Version Notification for draft-gondwana-effective-terminology-01.txt X-BeenThere: gendispatch@ietf.org 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: Wed, 26 Aug 2020 19:46:04 -0000 On 8/26/20 1:09 PM, Christian Huitema wrote: > We have a rough consensus to not use such terms in future documents If that rough consensus has been established, I've missed it. Keith From nobody Wed Aug 26 15:29:23 2020 Return-Path: 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 128F73A094E for ; Wed, 26 Aug 2020 15:29:22 -0700 (PDT) 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_H4=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=oUwabEHV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NQQh67bZ 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 nNgZOSGqbJu0 for ; Wed, 26 Aug 2020 15:29:20 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620BB3A094B for ; Wed, 26 Aug 2020 15:29:20 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 6552716C2 for ; Wed, 26 Aug 2020 18:29:19 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 26 Aug 2020 18:29:19 -0400 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:subject:content-type; s=fm3; bh=8SggfP7 X7ZRK/KuvmAEgH4JzFVIzuGA8sglKjpWNWPc=; b=oUwabEHVS8kkzbdnsl1KCwZ xosr+1xE29H9s98MZN3B2Kb4y/kDofJQpkWJgRBDaQcVptyWV8Yb8TlztJv92jEf nxoq7OBcE8ZK5OEdA8DrgZzkNPBxnwPiN8xEefmA2PFKPML9EEgqwf94R72xxXCu Co1XtNIIHIHIv2Os+ioc0KawrEJuwaFV91BroOtT3eOfD2oVCASo733Q7sziI/lr hpxZ3n9mZ9KmMG/2x954HNxWhET1vYWA83uJ0OA+LQW8NPzP43Nj6ZZzvFWukZBh elxStrDfVyMFdjMlP73p+hFZfAvRbPmOvh4ln963bS6fpEL4rcv66NIihbMS3+Q= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=fm3; bh=8SggfP 7X7ZRK/KuvmAEgH4JzFVIzuGA8sglKjpWNWPc=; b=NQQh67bZwFEgEj10t2Ca6m UwUjIrgH2bmoU8hZJq8DO/qBUQcZO/K4NwXnRlUAVxU4rRPAu0vOXQG+VZtwbBZN hyGUIyOC14vMFxxJd/kho2zSOemPGcP2Tu/UzO6kQ9kk+LGhD8A5lV9nnUt6xRwx qGO0dXKY2hvNO1jEeHlFLceeHKlcaHlnun+r7Kn3NsXzTXaC5bv058g6FWEXJQ5q UgkBapwk0hJyMostSZf+kE5mx/Lecdv+GYo+syfkkoKWpmgQ5VaocwXTjeZSIOEd 8moqp5PVXu9f+aqvwHajtvM1F5+31SFg1TNt9WKbvUIiAexyJg4WALDScys19UpA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvfedguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedtheetgeefve etudffveetheffgfehhfdvveekuefhheeuteduhefggeeikeejteenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrg hilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8F6B6180231; Wed, 26 Aug 2020 18:29:18 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-232-g4bdb081-fm-20200825.002-g4bdb081a Mime-Version: 1.0 Message-Id: <77c4222f-ea8c-4b06-ba22-584547e81b00@dogfood.fastmail.com> In-Reply-To: <005ff2af-63e0-db55-7dfd-7c95d2f32375@huitema.net> References: <3a30e4ad-1225-e440-efd9-2bf00339296d@gmail.com> <005ff2af-63e0-db55-7dfd-7c95d2f32375@huitema.net> Date: Thu, 27 Aug 2020 08:28:58 +1000 From: "Bron Gondwana" To: gendispatch@ietf.org Content-Type: multipart/alternative; boundary=87eae1d2109649468ec574ae04291c0e Archived-At: Subject: Re: [Gendispatch] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draf?= =?utf-8?q?t-gondwana-effective-terminology-01=2Etxt?= X-BeenThere: gendispatch@ietf.org 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: Wed, 26 Aug 2020 22:29:22 -0000 --87eae1d2109649468ec574ae04291c0e Content-Type: text/plain On Thu, Aug 27, 2020, at 03:09, Christian Huitema wrote: > > On 8/25/2020 9:02 PM, Bron Gondwana wrote: >> On Wed, Aug 26, 2020, at 06:51, Brian E Carpenter wrote: >>> Bron, >>> >>> Thanks for this. I like the tone and the choice of language. Just one remark: >>> >>> > 5. IANA Considerations >>> > >>> > This document does not ask the IANA to do anything (unless we decide >>> > that IANA is a good place for a central glossary to be kept) >>> >>> I think IANA would be a bad place for that, but my reaction was to identify >>> a missing section: >>> >>> 5a. RFC Editor Considerations >>> >>> This document does not ask the RFC Editor to do anything (unless we decide >>> that the RFC Editor site is a good place for a central glossary to be kept). >>> >>> On the other hand, maybe it isn't useful for us to keep any such glossary >>> anywhere. >> >> Good point :) I didn't expect that I'd get everything right in the firstsecond draft, so very happy to have feedback.. >> >> Without a glossary somewhere the document doesn't really do much at all other than defend the status quo and outline that the IETF generally follows terminology norms that are emerging in the wider community rather than forming them, which maybe has some value in itself - but at that point maybe there's no value in the document! > > Quick feedback to Bron: I like the tone of most of your draft, but you can't get away without addressing the specific issues listed by Mallory and Niels, "master-slave" and "white/black list". Well, I'm hoping I can avoid addressing those specific terms because they are a point-in-time issue, and I'm trying to establish what there is consensus on. My reading of the traffic on the IETF list is that there is quite definitely not consensus in the IETF on those specific terms. > Also, your security section has a marked departure in tone with a reference to "bad faith actors." We are witnessing a contentious debate in which I don't think participants are acting in "bad faith", rather than say, deeply held convictions. At a minimum, you need to change the tone, but I think you have to actually change the meaning, because that section goes too far. I'm happy to change the tone here. When I wrote this I was thinking of spurious things like "work is oppression and the word network is derived from work, so you need to remove the word network from all RFCs back into the past or you are oppressing me". There needs to be a reasonableness test that can declare that as being in bad faith or otherwise defend against it. > Suppose a reviewer calls out the use of obsolete metaphors in a last call review, pointing out for example the use of "master/slave". Your text as written empowers the WG chair to discard such comments because they "are harder to prove or evaluate than other claims". That's not the outcome that we want. We have a rough consensus to not use such terms in future documents, and WG chairs should not be directed to ignore that consensus. Fighting that consensus would also be a way "to derail the IETF from its mission, and to use the IETF's brand as clout in political battles" -- just a different side of the political battles. My text needs to empower the working group to discard the "network" case above. We already have mechanisms to deal with working group chairs who operate wildly outside the IETF's norms. We don't need a specific way to hit a chair over the head for rejecting a reviewer for this issue as opposed to rejecting a review for a technical issue. This is not directing chairs to ignore any consensus that might exist on any specific words over time, it's deliberately NOT giving this particular issue a different process than any other review. Regards, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --87eae1d2109649468ec574ae04291c0e Content-Type: text/html Content-Transfer-Encoding: quoted-printable


On Thu, Aug 27, 2020, at 03:09, Christian Huitema wrote:
=


On 8/25/2020 9:02 PM, Bron Gondwana wrote:
On Wed, Aug 26, 2020, at 06:51, Brian E Carpenter wrote:
Bron,

Thanks for this. I like the tone and the choice of language. Just one remark:

&g= t; 5.  IANA Considerations
> 
>  = ;  This document does not ask the IANA to do anything (unless we decide
>    that IANA is a good place for a central glossary to be kept)

I think= IANA would be a bad place for that, but my reaction was to identify
a missing section:

5a. = RFC Editor Considerations
   This document doe= s not ask the RFC Editor to do anything (unless we decide
   that the RFC Editor site is a good place for a central glossary to be kept).

= On the other hand, maybe it isn't useful for us to keep any such glossary
anywhere.

Good po= int :)  I didn't expect that I'd get everything right in the firstsecond draft, so very happy to have feedback..

Without a glossa= ry somewhere the document doesn't really do much at all other than defend the status quo and outline that the IETF generally follows terminology norms that are emerging in the wider community rather than forming them, which maybe has some value in itself -= but at that point maybe there's no value in the document!


Quick feedback to Bron: I like the tone of= most of your draft, but you can't get away without addressing the specific issues listed by Mallory and Niels, "master-slave" and "white/black list".


=
Well, I'm hoping I can avoid add= ressing those specific terms because they are a point-in-time issue, and= I'm trying to establish what there is consensus on.

My r= eading of the traffic on the IETF list is that there is quite definitely= not consensus in the IETF on those specific terms.

Also, your security section has a m= arked departure in tone with a reference to "bad faith actors." We are witnessing a contentious debate in which I don't think participants are acting in "bad faith", rather than say, deeply held convictions. At a minimum, you need to change the tone, but I think you have to actually change the meaning, because that section goes too far.

I'm happy to change the tone here.

When I wrote this I was thinking of spurious things like "work is op= pression and the word network is derived from work, so you need to remov= e the word network from all RFCs back into the past or you are oppressin= g me".  There needs to be a reasonableness test that can declare th= at as being in bad faith or otherwise defend against it.

Suppose a reviewer calls = out the use of obsolete metaphors in a last call review, pointing out for example the use of "master/slave". Your text as written empowers the WG chair to discard such comments because they "are harder to prove or evaluate than other claims". That's not the outcome that we want. We have a rough consensus to not use such terms in future documents, and WG chairs should not be directed to ignore that consensus. Fighting that consensus would also be a way "to derail the IETF from its mission, and to use the IETF's brand as clout in= political battles" -- just a different side of the political battles.
<= br>
My text needs to empower the = working group to discard the "network" case above.  We already have= mechanisms to deal with working group chairs who operate wildly outside= the IETF's norms.  We don't need a specific way to hit a chair ove= r the head for rejecting a reviewer for this issue as opposed to rejecti= ng a review for a technical issue.

This is not directing = chairs to ignore any consensus that might exist on any specific words ov= er time, it's deliberately NOT giving this particular issue a different = process than any other review.

Regards,

Br= on.

--
  Bron Gondwana, CEO, Fastmail Pty L= td
  brong@fastmailteam.com

<= /div>

--87eae1d2109649468ec574ae04291c0e-- From nobody Wed Aug 26 15:34:09 2020 Return-Path: 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 B729C3A0B3D for ; Wed, 26 Aug 2020 15:34:01 -0700 (PDT) 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_H4=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=Kxcfj4t8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ql/BMbaK 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 XqWHTmwwu08U for ; Wed, 26 Aug 2020 15:34:00 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F86D3A0BA1 for ; Wed, 26 Aug 2020 15:33:58 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id B03C2DD6 for ; Wed, 26 Aug 2020 18:33:57 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 26 Aug 2020 18:33:57 -0400 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:subject:content-type; s=fm3; bh=yoc8+h8 20JjDIKV1LKvIZtnbQ/8xKCKEEdjLOtMDZDA=; b=Kxcfj4t8Wi5EQ6K8JGZtuRT qTh2Tpih+njiXXaZzpDTqjCFpocmWHUgdU5pYFQV7YI3iNHNHbdFhm/G16gJrNGN V9vuF3WB4wqvo46qq5J8xC407dpWWly/goiBLAySltSjSwpvu8XC6MVPFC3MPca9 Ahbv2wk4fHAFatgtC4YZm/ww8QDaOZXMRioDushWdQN7r1DDDG7z/gbFuk8JwmQv z7g2S2juIVPye0+L0QxYpThU+VE+Vw+v2peIr6KqrGRRZClFPxBFzhJ9+cgWXqd2 aG1js1MTdEPY2cGKv+2/4RgitrFAQe8DQpyPwZXiFMejP70a12kIFnBRNZfPGXA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=fm3; bh=yoc8+h 820JjDIKV1LKvIZtnbQ/8xKCKEEdjLOtMDZDA=; b=ql/BMbaK+Pe1Z52JYvB9yG PKQM4Sq9jMikQdHXublFsoBaSChx2IlAVkEtE5x52WnYy3yo0Db+TQl3Ctxb22nV TkUn1T3PRGjfyBaG/VT06A4CSDDIKaIhCrX6YAUrBERohfOPpL9keyLdtBKopOO+ wBGFw11tPcrQzTVLBsXp0zqDeu5gx9KI1GtbRjuQK+/qGzuWYIaHrnu6E37Hcc+y x+5hZlpHmqjV/FyPKfDYZbduMBVk16aQ6VayD0YfZWSZjO0F+iw/uSstytbH+ucw frGoVAujqb6Nl/Y3GjK0rNu3SD87AkAYRDXWTdOj5Hk7+i78KTtyPMncFbwvfZ2A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvfedgudduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedtheetgeefve etudffveetheffgfehhfdvveekuefhheeuteduhefggeeikeejteenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrg hilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1B4B8180231; Wed, 26 Aug 2020 18:33:57 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-232-g4bdb081-fm-20200825.002-g4bdb081a Mime-Version: 1.0 Message-Id: <7094e644-bc54-4bd0-8309-850ff7dd71dd@dogfood.fastmail.com> In-Reply-To: <77c4222f-ea8c-4b06-ba22-584547e81b00@dogfood.fastmail.com> References: <3a30e4ad-1225-e440-efd9-2bf00339296d@gmail.com> <005ff2af-63e0-db55-7dfd-7c95d2f32375@huitema.net> <77c4222f-ea8c-4b06-ba22-584547e81b00@dogfood.fastmail.com> Date: Thu, 27 Aug 2020 08:33:36 +1000 From: "Bron Gondwana" To: gendispatch@ietf.org Content-Type: multipart/alternative; boundary=d2d2adc4df384b339c4900f8e851d6a5 Archived-At: Subject: Re: [Gendispatch] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draf?= =?utf-8?q?t-gondwana-effective-terminology-01=2Etxt?= X-BeenThere: gendispatch@ietf.org 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: Wed, 26 Aug 2020 22:34:08 -0000 --d2d2adc4df384b339c4900f8e851d6a5 Content-Type: text/plain On Thu, Aug 27, 2020, at 08:28, Bron Gondwana wrote: > > On Thu, Aug 27, 2020, at 03:09, Christian Huitema wrote: >> Quick feedback to Bron: I like the tone of most of your draft, but you can't get away without addressing the specific issues listed by Mallory and Niels, "master-slave" and "white/black list". > > Well, I'm hoping I can avoid addressing those specific terms because they are a point-in-time issue, and I'm trying to establish what there is consensus on. > > My reading of the traffic on the IETF list is that there is quite definitely not consensus in the IETF on those specific terms. Self-followup. To clarify I think there is close to a consensus that avoiding the word "slave" is worthwhile, and I would not expect to see new specifications using it. I don't believe there's consensus on deprecating b/w lists, or the word "master" when standalone or paired with different alternates. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --d2d2adc4df384b339c4900f8e851d6a5 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Thu, Aug 27, 2020, at 08:28, Bron Gondwana wrote:<= br>

On Thu, Aug 27, 2020, at 03:09, Christi= an Huitema wrote:

Quick feedback to Bron: I like the tone of most of your draft, but you can't get away without addressing the specific issues listed by Mallory and Niels, "master-slave" and "white/black list".


=
Well, I'm hoping I can avoid add= ressing those specific terms because they are a point-in-time issue, and= I'm trying to establish what there is consensus on.

My r= eading of the traffic on the IETF list is that there is quite definitely= not consensus in the IETF on those specific terms.

Self-followup.  To clarify I think there is close to a cons= ensus that avoiding the word "slave" is worthwhile, and I would not expe= ct to see new specifications using it.  I don't believe there's con= sensus on deprecating b/w lists, or the word "master" when standalone or= paired with different alternates.

Bron.

--
=
  Bron Gondwana, CEO, Fastmail Pty Ltd
  br= ong@fastmailteam.com


--d2d2adc4df384b339c4900f8e851d6a5-- From nobody Wed Aug 26 17:27:12 2020 Return-Path: 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 704AD3A0BC9 for ; Wed, 26 Aug 2020 17:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 ae4xnCBIZPJj for ; Wed, 26 Aug 2020 17:27:09 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E295A3A0BC2 for ; Wed, 26 Aug 2020 17:27:08 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 0431C177F for ; Wed, 26 Aug 2020 20:27:07 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 26 Aug 2020 20:27:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=fm3; bh=pXLP90 U7N0Zr8GbptVwzgMMLLSpEchzbyUOJpqgDkxc=; b=EQcDRkmQhoiVoJy4xAjbpy pWrM7JMFl8gTcdwu+6GYTU3/RabS5yMNgt2veJrvFUDVq6YXuUu3jrZWTvGmUjLO qMt2m4kWhgfiDTjaezhy7rO9LV0Rl76rGp6/Pe3aE7x02s+9q3toEhO+oMCIcrIJ gySAyA+Tcq6ll/hLP7ETqU4ra2BDTUIQCmuWRWuXvvKmj+/Mn8X3k669LXSh9mYA 3TdAXnx6ZwbAoaRcEB0FXqYwBsbkSpFTt2M9ZNLaJ01j+mEcLoJowb8igtTQdyJH PrU3K+BUC3Kh8QuV1GnIzcJi/g5LjCbyub8Loq2B7zT22KbAZamTOJxr6ILvz/Dg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvfedgfeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpehfuffvhffkffgfgggjtgesmhdtre ertdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepiedvleejtdegge efgeevieeitedvkefgueeukeeugffghfeitddtkeehtdevfeeknecukfhppedutdekrddv vddurddukedtrdduheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 12F9B30600DC for ; Wed, 26 Aug 2020 20:27:06 -0400 (EDT) References: <159848790676.31401.17151257967664129305@ietfa.amsl.com> To: gendispatch@ietf.org From: Keith Moore X-Forwarded-Message-Id: <159848790676.31401.17151257967664129305@ietfa.amsl.com> Message-ID: Date: Wed, 26 Aug 2020 20:27:05 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <159848790676.31401.17151257967664129305@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------1D9C69BF7FCF99C39B4AC434" Content-Language: en-US Archived-At: Subject: [Gendispatch] Fwd: New Version Notification for draft-moore-exclusionary-language-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 00:27:10 -0000 This is a multi-part message in MIME format. --------------1D9C69BF7FCF99C39B4AC434 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Ok, after the usual many hours of wrangling with the i-d submission tools, my draft is finally posted. At least in this form I'm intending this draft to be more of a topic for discussion than a candidate for publication. I look forward to the real-time meeting. Keith --------------1D9C69BF7FCF99C39B4AC434 Content-Type: message/rfc822; name="New Version Notification for draft-moore-exclusionary-language-00_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="New Version Notification for draft-moore-exclusionary-langua"; filename*1="ge-00_txt.eml" Return-Path: Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by sloti6d1t26 (Cyrus 3.3.0-232-g4bdb081-fm-20200825.002-g4bdb081a) with LMTPA; Wed, 26 Aug 2020 20:25:10 -0400 X-Cyrus-Session-Id: sloti6d1t26-1598487910-445075-2-14498935818674247823 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-charsets: plain='utf-8' X-Delivered-to: moore@network-heretics.com X-Mail-from: internet-drafts@ietf.org Received: from wgp2 ([10.209.2.42]) by compute1.internal (LMTPProxy); Wed, 26 Aug 2020 20:25:10 -0400 Received: from wmx2.messagingengine.com (localhost [127.0.0.1]) by mailmx.west.internal (Postfix) with ESMTP id E08C9AC2152 for ; Wed, 26 Aug 2020 20:25:09 -0400 (EDT) Received: from wmx2.messagingengine.com (localhost [127.0.0.1]) by wmx2.messagingengine.com (Authentication Milter) with ESMTP id 1B884C3EB15; Wed, 26 Aug 2020 20:25:09 -0400 ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=fm3; t= 1598487909; b=X8XrmNSo1Fl2bYD97bEqVuuLLBtsWAwi5D2SQai86/eSr/C8Zv 7Xze2u23x03yhEyhVnsS2VK0o5vBc/TyCgJwS8SC6YTW5c6WIuySfNEz6scQkiNk y6D7AlVyEMq1hrA+ndbWEklaXjDUJPO+G/W07+M0fv4mgfJ2ffYTMSc3riF905/K 5+/VyT/iy21HY07ldFuSKqxYzFlHv6V3OAOOJvMvfOqKupAOoPW0BeX9nlKdZO/4 huRstdrZpabATwcDNLYEnVhIf0zjkcQGC9DGVEZ4rxpE/Ek70g0xoyJPoFjj2k6z 3upKA9SHx+ZZ3WYKj3XZMl8jmDSXN2lofdyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=mime-version:content-type :content-transfer-encoding:from:to:subject:message-id:date; s= fm3; t=1598487909; bh=EN0ubZGtm7o6NOdTGv/WiPocNl9RsyOigzMDN3rYFj 0=; b=piuQO+rO7l+8CTN9r+OqmlXmUZwBj9mQf29NbHGhpoZMreU5iEs0of3/hL GcTBWYqo2TUvdlFIs6sD/QmlCO4nrFOB4l4Ox/ondWhP/Zo4HMOikvzJQ8i4cFiy +4srHCvoGzD02plhnLoYvRniOM22DCeDaQeuC1igVi5i1AAe0wC0QTyhEVFcGadu rJvb6CldHfcEOhNX2EBfyqNW/Y5zxdBrVWJNc1enC0WzHQzwvUJ01Dn+hDubpAvK HXCS5pMdwgEEkxo6dYicPDRGeBjexrAqA2kTEgS7UTCLW1CqV/qDlqUMyDszxa16 EXDidCSzu9vryzZPD3K55szfuwVA== ARC-Authentication-Results: i=1; wmx2.messagingengine.com; arc=none (no signatures found); bimi=none (Domain is not BIMI enabled); dkim=none (no signatures found); dmarc=pass policy.published-domain-policy=none policy.applied-disposition=none policy.evaluated-disposition=none (p=none,d=none,d.eval=none) policy.policy-from=p header.from=ietf.org; iprev=pass smtp.remote-ip=4.31.198.44 (mail.ietf.org); spf=pass smtp.mailfrom=internet-drafts@ietf.org smtp.helo=mail.ietf.org; x-aligned-from=pass (Address match); x-ptr=pass smtp.helo=mail.ietf.org policy.ptr=mail.ietf.org; x-return-mx=pass header.domain=ietf.org policy.is_org=yes (MX Records found: mail.ietf.org); x-return-mx=pass smtp.domain=ietf.org policy.is_org=yes (MX Records found: mail.ietf.org); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES128-GCM-SHA256 smtp.bits=128/128; x-vs=clean score=-100 state=0 Authentication-Results: wmx2.messagingengine.com; arc=none (no signatures found); bimi=none (Domain is not BIMI enabled); dkim=none (no signatures found); dmarc=pass policy.published-domain-policy=none policy.applied-disposition=none policy.evaluated-disposition=none (p=none,d=none,d.eval=none) policy.policy-from=p header.from=ietf.org; iprev=pass smtp.remote-ip=4.31.198.44 (mail.ietf.org); spf=pass smtp.mailfrom=internet-drafts@ietf.org smtp.helo=mail.ietf.org; x-aligned-from=pass (Address match); x-ptr=pass smtp.helo=mail.ietf.org policy.ptr=mail.ietf.org; x-return-mx=pass header.domain=ietf.org policy.is_org=yes (MX Records found: mail.ietf.org); x-return-mx=pass smtp.domain=ietf.org policy.is_org=yes (MX Records found: mail.ietf.org); x-tls=pass smtp.version=TLSv1.2 smtp.cipher=ECDHE-RSA-AES128-GCM-SHA256 smtp.bits=128/128; x-vs=clean score=-100 state=0 Received-SPF: pass (ietf.org: 4.31.198.44 is authorized to use 'internet-drafts@ietf.org' in 'mfrom' identity (mechanism 'ip4:4.31.198.32/27' matched)) receiver=wmx2.messagingengine.com; identity=mailfrom; envelope-from="internet-drafts@ietf.org"; helo=mail.ietf.org; client-ip=4.31.198.44 Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by wmx2.messagingengine.com (Postfix) with ESMTPS for ; Wed, 26 Aug 2020 20:25:09 -0400 (EDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BF06D3A0BC9 for ; Wed, 26 Aug 2020 17:25:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: "Keith Moore" Subject: New Version Notification for draft-moore-exclusionary-language-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159848790676.31401.17151257967664129305@ietfa.amsl.com> Date: Wed, 26 Aug 2020 17:25:06 -0700 A new version of I-D, draft-moore-exclusionary-language-00.txt has been successfully submitted by Keith Moore and posted to the IETF repository. Name: draft-moore-exclusionary-language Revision: 00 Title: Avoiding Exclusionary Language in RFCs Document date: 2020-08-26 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-moore-exclusionary-language-00.txt Status: https://datatracker.ietf.org/doc/draft-moore-exclusionary-language/ Htmlized: https://tools.ietf.org/html/draft-moore-exclusionary-language-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-moore-exclusionary-language Abstract: It has been asserted that some language in IETF documents is "exclusionary" - that it offends some readers or groups of people, and/or discourages participation in IETF by doing so. While there is some debate about exactly which language is exclusionary, at least some cited examples of such language can credibly have such effects. It is believed that most instances of such language are accidental, and that most document authors and editors wish to avoid use of language that may be offensive. This memo therefore attempts to establish procedures that warn document authors and editors about language that may credibly having such effects, and thereby, to reduce both accidental and deliberate use of such language. At the same time, it is recognized that in some cases there an be strong and conflicting opinions about whether or not particular language is desirable or appropriate. IETF's primary function is providing technical direction for the benefit of the Internet community, rather than social engineering. If a document can be blocked or substantially delayed over disputes about the proprietary of language in that document, this can be disruptive to IETF's primary function. This memo therefore makes recommendations to prevent such disputes from blocking progress on technical documents. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------1D9C69BF7FCF99C39B4AC434-- From nobody Wed Aug 26 17:33:23 2020 Return-Path: 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 9BF923A0BDA for ; Wed, 26 Aug 2020 17:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 llaiQM9GIhzr for ; Wed, 26 Aug 2020 17:33:19 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE683A0BD9 for ; Wed, 26 Aug 2020 17:33:19 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 41F4616BE for ; Wed, 26 Aug 2020 20:33:19 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 26 Aug 2020 20:33:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=IC1mnF6H65HUut/3e071AjpEUAac54C4y7bC4V397 4s=; b=S6hjn6LxReQnMiNJL+8wTwckv43Zs8Ggzjg02qBIVtNBik5F9pX/Kg32c Yco4+CNU7Jfsu1mLvlg8787jQ0BXmhZjPrt+1T3k2+B5IRyiBySeYnvqRTs6XZjC Vu279E9P5w9gAj4RJjmgINnTCfe+/+RAGAZ6nc9yZfKwtIVHyVWgH6TokiN1CKaQ 0cfIvwate3rRfj436GfIAgcDb+qzekzh3iDcNDgrCapd6BDGus/pzz5LPetrgiwg 4W+yJ/itaqKIgRhNr8EaE0KMJLzF/fw0tlsqc0/9bP30JSb+MI0KgpPqOITv6Fsx tYqxpJqvTZLp54FypT1Wfm7/z3cTg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvfedgfeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtje ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeekvdeggfelue elkeeuhfffheeghffhkeeuvdduudeihfehudefffdtgfdtkeffgfenucfkphepuddtkedr vddvuddrudektddrudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 1E3693060701 for ; Wed, 26 Aug 2020 20:33:17 -0400 (EDT) To: gendispatch@ietf.org References: From: Keith Moore Message-ID: <9d4d6a3f-934d-0cc9-45fc-e86554a2ed35@network-heretics.com> Date: Wed, 26 Aug 2020 20:33:16 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] Fwd: New Version Notification for draft-gondwana-effective-terminology-01.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 00:33:21 -0000 For what it's worth, I'm generally in support of Bron's draft. I view our drafts as potentially complimentary to one another rather than competing. (I didn't read his draft until I finished mine.) Keith From nobody Thu Aug 27 01:54:24 2020 Return-Path: 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 3653B3A0772 for ; Thu, 27 Aug 2020 01:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 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 LW9DJe9eOMbt for ; Thu, 27 Aug 2020 01:54:20 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042223A0770 for ; Thu, 27 Aug 2020 01:54:19 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1kBDfj-0001Uj-Pr for gendispatch@ietf.org; Thu, 27 Aug 2020 10:54:16 +0200 To: gendispatch@ietf.org From: Niels ten Oever Autocrypt: addr=lists@digitaldissidents.org; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtC1OaWVscyB0ZW4g T2V2ZXIgPGxpc3RzQGRpZ2l0YWxkaXNzaWRlbnRzLm9yZz6JAj8EEwEIACkFAlgvB3YCGyMF CQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRAO2D86RorIs56yD/44BSJvKnjH ex0nhPDI9nIJlzlnypa4qsniy0obG5GRbVRikT1E1xaz7VBoPs39hCywoIWd6p0hs1PG1Tcj WV0GwNKRt90PPEh6iNJSGjV2Aq3IlME/aUViD9008yfbRSqfsnPXLW1kpCoZNaOSNzpURoM9 OkVU/z4LSLD61SfFFByBne/GkJKt96/fcspBif1GPC//63ZKFrDqQ9JFR6dECAmsKv7baayz MTv3wrTcqpuHcqJIv4vTm8IPx1QiGgEvrMwsPZz/vx8bMdxxxHWgCcbrt+0b3tRzq9ATZwG3 xDiwnJgKd+ioZOC/b5sY69721sqwBmWYyXWVqtqt01xIgNZjr/wixam+l1bTGUgj0rwPWJWx +7Whe25ff+mNNW/UQeCBjZlxoxAJWSr1Pp3n+SQKQ4TLs8wIwHZtcVCffepfHd47CEbnR8Kc Tjm3tlKzSWq4zcUy6BaxHfgn9+HaAM7fwLqx9/WAtSfdmLXJTN+Swy0w/slakD75jl2o7U3e ETjoYQWt+306X2Uly/0ge7VEQ4ySmmbru6U5ainGE95gjsc++s+hvKmMuGYL3h4ijE1RSe/k wgM6/Z1B6JosssdX+KRuuk2A4FHGbcee8LUIJ3C36qyI7s6PJBXi6SjIPN0wpx30P/DUf/Lr o5lmHF03qQ5eeqI8lDwIobWlJbkCDQRYKXEdARAAxYOE3/AFmEfQ0SVVFujYFhZKX+BGXolY ytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fxj+uXvLKAm9xQRI/DCug7/NGULMk9 bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHwyIawsSCN9AhDXZQWVRqkR1QXcq3I YKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVOBR8xUCBbyk5aRW4VSGO6pUD3H21u r+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8ITaNdFSAttkdT56wAQpxE2h8zaOmBa FUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZtPP9gIX+ic8QO5iuct37bRXJU/rm rH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJHE8JMaX0yYT6h4PGRS3mNM4bka8hj dfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCVaTfJLFPEru3drxNwi6ogdkRmcLGK qqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+uPlDtuExehLsNOMpjP8qhZpFtyLe DS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwODyVwk3MK5Em4pJ0+IAJx+F6gta0B k2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAKCRAO2D86RorIs0ykD/4t151SZG9M beKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvbgB4CtkBuXQlq+plOBWv+rFEThOzy 3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK83OGnfM02qP1Ky8d7EoZz+nTSMf/ DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9Oy1wWy6fHjwx3r+wQSokBNfxgQyAF onmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDvLwOUYKevBIeJJcqTyfAn3TtJbPCE HOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWvKKmBNBB5OJ/rmHogbNU+wWPJ723q MBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiGpWv4tMc5oB/qVh3my1VO65ErcJ3S 9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJBX6jeYZabGvnTicQlBAzfGpblFqV 3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0OhbnytnopKJKk99bwMoCqDkfQvT3 LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ9DYmtE40zO6g70VVxUj+dKt2hbJT y/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> Date: Thu, 27 Aug 2020 10:54:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: 29cc722430e8f1f6ed904119444c0d49b0f3ee91 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 71684ae416b12bc74806129cb02de027 Archived-At: Subject: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 08:54:22 -0000 Dear all, draft-moore-exclusionary-language and draft-gondwana-effective-terminology both seem very concerned with the potential for disruption of IETF processes if one were to provide measures for the discussion of the issue of exclusionary language in new I-Ds and RFCs. Both drafts also seem to find it very important that if there is a (perceived) issue, this should be extensively documented with evidence in the form of citations and numbers. However, both drafts don't provide any citations or quantification to back up their own assertions and recommendations. I think it would be very useful for a constructive discussion if the draft authors could perhaps provide a bit more grounding to their arguments. This could for example be in scientific literature, or perhaps by showing observed disruptions in similar or adjacent communities to the IETF that have already instated such measures (such as Python, Django, Linux Project, Bluetooth SIG, Drupal, Postgres, NIST, RedHat, etc). Best, Niels -- Niels ten Oever Researcher and PhD Candidate - DATACTIVE Research Group - University of Amsterdam Postdoctoral Scholar (abd) - Communications Department - Texas A&M University Research Fellow - Centre for Internet and Human Rights - European University Viadrina Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas W: https://nielstenoever.net E: mail@nielstenoever.net T: @nielstenoever P/S/WA: +31629051853 PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Thu Aug 27 02:10:27 2020 Return-Path: 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 5CD9F3A0831 for ; Thu, 27 Aug 2020 02:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.847 X-Spam-Level: X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=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=messagingengine.com 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 rrzRkxdKUtM9 for ; Thu, 27 Aug 2020 02:10:24 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 069263A082E for ; Thu, 27 Aug 2020 02:10:23 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 1DB3BF88 for ; Thu, 27 Aug 2020 05:10:23 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 27 Aug 2020 05:10:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=F5FamHh+zFjoTjZVAU8JgDR50auqDBOXYMcpxCMv2 VU=; b=oQNnDvUUZskDztgFYjQmmNvZHXgcRfuFuQ4h4rjchKJr5GZ9A/oWfpvHf 06Tv1b7pHz5iAKhOCCDSb1VMq4c7cf1ZrLgJdRzBrAsW39Q4pbhq1YaMMdUD+Abg GkjhLe8mDUqztkxOMp4IS5P+KFdeUJTdYhnMDzeFIphduCM0ZvMPeeaWUnTpV2kj 65KUJpWncpxo1DhgypoPgOVc8BSIdOIEXld4e6f2m0qcPxCdX6b+cSETKz3TjJLk nX+2or2K8tNlkG2LIvz/ORHAymGR7Fn2irm0gthT1oMzO92zIqtjcnyCezaU4sIr WaNq7sNY1twa6zS00O5CIkqlimlaw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvgedguddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeehhfeutdehfe fgfefghfekhefguefgieduueegjeekfeelleeuieffteefueduueenucfkphepuddtkedr vddvuddrudektddrudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 7E99830600B2 for ; Thu, 27 Aug 2020 05:10:21 -0400 (EDT) To: gendispatch@ietf.org References: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> From: Keith Moore Message-ID: Date: Thu, 27 Aug 2020 05:10:19 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 09:10:25 -0000 On 8/27/20 4:54 AM, Niels ten Oever wrote: > Dear all, > > draft-moore-exclusionary-language and draft-gondwana-effective-terminology both seem very concerned with the potential for disruption of IETF processes if one were to provide measures for the discussion of the issue of exclusionary language in new I-Ds and RFCs. Both drafts also seem to find it very important that if there is a (perceived) issue, this should be extensively documented with evidence in the form of citations and numbers. To clarify somewhat, my draft says that when an aggrieved party perceives an issue and complains about it, that should be treated as sincere. My intent is that when some third party perceives an issue and complains about that issue on behalf of some aggrieved party, substantiation should be required before such a claim is regarded as credible. > However, both drafts don't provide any citations or quantification to back up their own assertions and recommendations. I think it would be very useful for a constructive discussion if the draft authors could perhaps provide a bit more grounding to their arguments. My draft was written assuming an audience of experienced IETF participants who likely have personal experience of such disruption.   Much like an aggrieved party who has personal experience of being excluded should not have that personal experience questioned, experienced IETF participants who have experienced how discussions can get out of hand, should not have to prove that their personal experiences are valid. More broadly, the burden of proof should be on those demanding potentially disruptive changes, not on those who have long experience with consensus-based decision making in IETF. The recent discussions on the ietf@ list are but one example of how these discussions can get out of hand. Keith From nobody Thu Aug 27 02:21:51 2020 Return-Path: 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 EC9FA3A0840 for ; Thu, 27 Aug 2020 02:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, 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 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 EV42xlaOt3-T for ; Thu, 27 Aug 2020 02:21:47 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD413A083F for ; Thu, 27 Aug 2020 02:21:46 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1kBE6K-0007lX-Od for gendispatch@ietf.org; Thu, 27 Aug 2020 11:21:45 +0200 To: gendispatch@ietf.org References: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> From: Niels ten Oever Autocrypt: addr=lists@digitaldissidents.org; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtC1OaWVscyB0ZW4g T2V2ZXIgPGxpc3RzQGRpZ2l0YWxkaXNzaWRlbnRzLm9yZz6JAj8EEwEIACkFAlgvB3YCGyMF CQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRAO2D86RorIs56yD/44BSJvKnjH ex0nhPDI9nIJlzlnypa4qsniy0obG5GRbVRikT1E1xaz7VBoPs39hCywoIWd6p0hs1PG1Tcj WV0GwNKRt90PPEh6iNJSGjV2Aq3IlME/aUViD9008yfbRSqfsnPXLW1kpCoZNaOSNzpURoM9 OkVU/z4LSLD61SfFFByBne/GkJKt96/fcspBif1GPC//63ZKFrDqQ9JFR6dECAmsKv7baayz MTv3wrTcqpuHcqJIv4vTm8IPx1QiGgEvrMwsPZz/vx8bMdxxxHWgCcbrt+0b3tRzq9ATZwG3 xDiwnJgKd+ioZOC/b5sY69721sqwBmWYyXWVqtqt01xIgNZjr/wixam+l1bTGUgj0rwPWJWx +7Whe25ff+mNNW/UQeCBjZlxoxAJWSr1Pp3n+SQKQ4TLs8wIwHZtcVCffepfHd47CEbnR8Kc Tjm3tlKzSWq4zcUy6BaxHfgn9+HaAM7fwLqx9/WAtSfdmLXJTN+Swy0w/slakD75jl2o7U3e ETjoYQWt+306X2Uly/0ge7VEQ4ySmmbru6U5ainGE95gjsc++s+hvKmMuGYL3h4ijE1RSe/k wgM6/Z1B6JosssdX+KRuuk2A4FHGbcee8LUIJ3C36qyI7s6PJBXi6SjIPN0wpx30P/DUf/Lr o5lmHF03qQ5eeqI8lDwIobWlJbkCDQRYKXEdARAAxYOE3/AFmEfQ0SVVFujYFhZKX+BGXolY ytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fxj+uXvLKAm9xQRI/DCug7/NGULMk9 bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHwyIawsSCN9AhDXZQWVRqkR1QXcq3I YKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVOBR8xUCBbyk5aRW4VSGO6pUD3H21u r+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8ITaNdFSAttkdT56wAQpxE2h8zaOmBa FUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZtPP9gIX+ic8QO5iuct37bRXJU/rm rH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJHE8JMaX0yYT6h4PGRS3mNM4bka8hj dfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCVaTfJLFPEru3drxNwi6ogdkRmcLGK qqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+uPlDtuExehLsNOMpjP8qhZpFtyLe DS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwODyVwk3MK5Em4pJ0+IAJx+F6gta0B k2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAKCRAO2D86RorIs0ykD/4t151SZG9M beKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvbgB4CtkBuXQlq+plOBWv+rFEThOzy 3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK83OGnfM02qP1Ky8d7EoZz+nTSMf/ DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9Oy1wWy6fHjwx3r+wQSokBNfxgQyAF onmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDvLwOUYKevBIeJJcqTyfAn3TtJbPCE HOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWvKKmBNBB5OJ/rmHogbNU+wWPJ723q MBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiGpWv4tMc5oB/qVh3my1VO65ErcJ3S 9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJBX6jeYZabGvnTicQlBAzfGpblFqV 3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0OhbnytnopKJKk99bwMoCqDkfQvT3 LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ9DYmtE40zO6g70VVxUj+dKt2hbJT y/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: Date: Thu, 27 Aug 2020 11:21:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: 29cc722430e8f1f6ed904119444c0d49b0f3ee91 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 0cb660a7d4ce909c6359c48b0bded22a Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 09:21:50 -0000 Dear Keith, On 8/27/20 11:10 AM, Keith Moore wrote: > On 8/27/20 4:54 AM, Niels ten Oever wrote: > >> Dear all, >> >> draft-moore-exclusionary-language and draft-gondwana-effective-terminology both seem very concerned with the potential for disruption of IETF processes if one were to provide measures for the discussion of the issue of exclusionary language in new I-Ds and RFCs. Both drafts also seem to find it very important that if there is a (perceived) issue, this should be extensively documented with evidence in the form of citations and numbers. > > To clarify somewhat, my draft says that when an aggrieved party perceives an issue and complains about it, that should be treated as sincere. I think that exclusionary language aggrieves (or should aggrieve) everyone, because it leads to less diverse communities. It has been proven time and again that less diverse communities produce lesser quality work than diverse communities. See also RFC7704 and a wide range of academic literature on this topic. > > My intent is that when some third party perceives an issue and complains about that issue on behalf of some aggrieved party, substantiation should be required before such a claim is regarded as credible. > I am not sure what makes an aggrieved party. As discussed above, exclusionary language is a problem for everyone. >> However, both drafts don't provide any citations or quantification to back up their own assertions and recommendations. I think it would be very useful for a constructive discussion if the draft authors could perhaps provide a bit more grounding to their arguments. > > My draft was written assuming an audience of experienced IETF participants who likely have personal experience of such disruption.   Much like an aggrieved party who has personal experience of being excluded should not have that personal experience questioned, experienced IETF participants who have experienced how discussions can get out of hand, should not have to prove that their personal experiences are valid. > > More broadly, the burden of proof should be on those demanding potentially disruptive changes, not on those who have long experience with consensus-based decision making in IETF. I don't think draft-knodel-terminology asks for disruptive changes, it asks for voluntary removal of exclusionary language of new RFCs and I-Ds. I do not see how that is disruptive. If that is disruptive, we have another kind of problem. As mentioned, other communities have made this commitment and I have not seen any case of disruption. But feel free to point us to it. Best, Niels > > The recent discussions on the ietf@ list are but one example of how these discussions can get out of hand. > > Keith > > -- Niels ten Oever Researcher and PhD Candidate - DATACTIVE Research Group - University of Amsterdam Postdoctoral Scholar (abd) - Communications Department - Texas A&M University Research Fellow - Centre for Internet and Human Rights - European University Viadrina Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas W: https://nielstenoever.net E: mail@nielstenoever.net T: @nielstenoever P/S/WA: +31629051853 PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Thu Aug 27 03:12:15 2020 Return-Path: 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 1C2A93A0952 for ; Thu, 27 Aug 2020 03:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 lLx-r43F1rUt for ; Thu, 27 Aug 2020 03:12:11 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285513A0EF3 for ; Thu, 27 Aug 2020 03:11:27 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 3FA923DB for ; Thu, 27 Aug 2020 06:11:26 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 27 Aug 2020 06:11:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=epe0crtZa7uWcEksW0WpArhKGi8fZd8YQOcj30OQr UE=; b=nwIeXSezlsv6kS8cwxkmJNKCeot6dQjhkbxFtNUDLJoHG8G1c3FHFWg9o //tNgploQlMPHvC98kTfb+zppdtiVP46Ee301ppyRJtfuE3bLWpbMieOU7Lzd3WC EyVtUWfbpiBaqlkGN4O+llinx+hIAFhDRqi+BuDsiA6it7RGP9iRUUnjnsLvPpa6 XuXjUvgltEKh1GbLw+CnwXqJ+hQfg9jk40ij3/Rnht0wS6iAjyRSXQzx8kr0nsaU NYIaZy6W1fX0L7qjxDio+3In8g4DjPVS5/R3reN4IBedXZkxOS/Q8tMeOpVgy41F z+e21TdxbJAckYZ4od/jJqN8nbpsA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvgedgvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeehhfeutdehfe fgfefghfekhefguefgieduueegjeekfeelleeuieffteefueduueenucfkphepuddtkedr vddvuddrudektddrudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 417F0306005F for ; Thu, 27 Aug 2020 06:11:25 -0400 (EDT) To: gendispatch@ietf.org References: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> From: Keith Moore Message-ID: <9584b8b1-a4dd-5a41-ffba-93df5d780f23@network-heretics.com> Date: Thu, 27 Aug 2020 06:11:23 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 10:12:14 -0000 On 8/27/20 5:21 AM, Niels ten Oever wrote: >> To clarify somewhat, my draft says that when an aggrieved party perceives an issue and complains about it, that should be treated as sincere. > I think that exclusionary language aggrieves (or should aggrieve) everyone, because it leads to less diverse communities. Perhaps, but who gets to decide what is exclusionary?   Surely the aggrieved parties are in a better position to make such claims, than third parties purporting to speak on their behalf without supporting evidence. >> More broadly, the burden of proof should be on those demanding potentially disruptive changes, not on those who have long experience with consensus-based decision making in IETF. > I don't think draft-knodel-terminology asks for disruptive changes, it asks for voluntary removal of exclusionary language of new RFCs and I-Ds. I do not see how that is disruptive. If that is disruptive, we have another kind of problem. I haven't read the latest version so this comment will be based on the previous version.   I mostly agree that the specific changes mentioned in the previous draft are uncontroversial unlikely to be disruptive. The problem as I see it is that bring up the subject invites some people to try to find as many words as possible to exclude from the language, and some of those suggestions are controversial. > As mentioned, other communities have made this commitment and I have not seen any case of disruption. But feel free to point us to it. Other communities have different purposes and different rules. I don't want to dissect each community and try to analyze how each one manages its internal conflicts, or whether the narrow scope of the community afforded them some insulation from potential controversy not afforded to IETF, and gauge how predictive each community's experience would be for IETF.  We don't need to resort to dubious analogies, we have already witnessed firsthand a small taste of how this specific discussion can be disruptive to IETF. You claim you're asking for "voluntary" removal.  But what does "voluntary" mean?   In IETF some people have the power to compel authors to edit their language, else have their work discarded or lose influence over their work (depending on IPR terms chosen by the author).   So in the context of IETF the question of censorship inherently comes up, and it's certainly not a surprise that censorship is a controversial topic. This is a Pandora's box, or a can of worms - pick whatever analogy you wish.   It's something that has a large potential for undesirable unintended consequences. But anticipating and managing potential unintended consequences is a big part of what engineers do.   So please don't fault us for trying to do that.   Some of us are just trying to figure out how to manage the occasional disruptive corner cases that we believe, based on our experiences, are likely to crop up if we move in the direction you want us to move.   My personal sense is that most of what you want is uncontroversial and that there's a likelihood of earning consensus IFF measures to limit the potential for disruption can be agreed on. Keith From nobody Thu Aug 27 03:31:37 2020 Return-Path: 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 D30DD3A09A6 for ; Thu, 27 Aug 2020 03:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, 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 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 MKTnkAMNsJdE for ; Thu, 27 Aug 2020 03:31:33 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79EE33A09D8 for ; Thu, 27 Aug 2020 03:31:32 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1kBFBo-0006GF-S9 for gendispatch@ietf.org; Thu, 27 Aug 2020 12:31:29 +0200 To: gendispatch@ietf.org References: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> <9584b8b1-a4dd-5a41-ffba-93df5d780f23@network-heretics.com> From: Niels ten Oever Autocrypt: addr=lists@digitaldissidents.org; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtC1OaWVscyB0ZW4g T2V2ZXIgPGxpc3RzQGRpZ2l0YWxkaXNzaWRlbnRzLm9yZz6JAj8EEwEIACkFAlgvB3YCGyMF CQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRAO2D86RorIs56yD/44BSJvKnjH ex0nhPDI9nIJlzlnypa4qsniy0obG5GRbVRikT1E1xaz7VBoPs39hCywoIWd6p0hs1PG1Tcj WV0GwNKRt90PPEh6iNJSGjV2Aq3IlME/aUViD9008yfbRSqfsnPXLW1kpCoZNaOSNzpURoM9 OkVU/z4LSLD61SfFFByBne/GkJKt96/fcspBif1GPC//63ZKFrDqQ9JFR6dECAmsKv7baayz MTv3wrTcqpuHcqJIv4vTm8IPx1QiGgEvrMwsPZz/vx8bMdxxxHWgCcbrt+0b3tRzq9ATZwG3 xDiwnJgKd+ioZOC/b5sY69721sqwBmWYyXWVqtqt01xIgNZjr/wixam+l1bTGUgj0rwPWJWx +7Whe25ff+mNNW/UQeCBjZlxoxAJWSr1Pp3n+SQKQ4TLs8wIwHZtcVCffepfHd47CEbnR8Kc Tjm3tlKzSWq4zcUy6BaxHfgn9+HaAM7fwLqx9/WAtSfdmLXJTN+Swy0w/slakD75jl2o7U3e ETjoYQWt+306X2Uly/0ge7VEQ4ySmmbru6U5ainGE95gjsc++s+hvKmMuGYL3h4ijE1RSe/k wgM6/Z1B6JosssdX+KRuuk2A4FHGbcee8LUIJ3C36qyI7s6PJBXi6SjIPN0wpx30P/DUf/Lr o5lmHF03qQ5eeqI8lDwIobWlJbkCDQRYKXEdARAAxYOE3/AFmEfQ0SVVFujYFhZKX+BGXolY ytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fxj+uXvLKAm9xQRI/DCug7/NGULMk9 bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHwyIawsSCN9AhDXZQWVRqkR1QXcq3I YKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVOBR8xUCBbyk5aRW4VSGO6pUD3H21u r+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8ITaNdFSAttkdT56wAQpxE2h8zaOmBa FUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZtPP9gIX+ic8QO5iuct37bRXJU/rm rH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJHE8JMaX0yYT6h4PGRS3mNM4bka8hj dfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCVaTfJLFPEru3drxNwi6ogdkRmcLGK qqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+uPlDtuExehLsNOMpjP8qhZpFtyLe DS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwODyVwk3MK5Em4pJ0+IAJx+F6gta0B k2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAKCRAO2D86RorIs0ykD/4t151SZG9M beKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvbgB4CtkBuXQlq+plOBWv+rFEThOzy 3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK83OGnfM02qP1Ky8d7EoZz+nTSMf/ DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9Oy1wWy6fHjwx3r+wQSokBNfxgQyAF onmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDvLwOUYKevBIeJJcqTyfAn3TtJbPCE HOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWvKKmBNBB5OJ/rmHogbNU+wWPJ723q MBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiGpWv4tMc5oB/qVh3my1VO65ErcJ3S 9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJBX6jeYZabGvnTicQlBAzfGpblFqV 3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0OhbnytnopKJKk99bwMoCqDkfQvT3 LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ9DYmtE40zO6g70VVxUj+dKt2hbJT y/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: Date: Thu, 27 Aug 2020 12:31:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <9584b8b1-a4dd-5a41-ffba-93df5d780f23@network-heretics.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: 29cc722430e8f1f6ed904119444c0d49b0f3ee91 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 3ced5df4177ef3a93a84b902ce7c160e Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 10:31:36 -0000 Dear Keith, On 8/27/20 12:11 PM, Keith Moore wrote: > On 8/27/20 5:21 AM, Niels ten Oever wrote: > >>> To clarify somewhat, my draft says that when an aggrieved party perceives an issue and complains about it, that should be treated as sincere. >> I think that exclusionary language aggrieves (or should aggrieve) everyone, because it leads to less diverse communities. > > Perhaps, but who gets to decide what is exclusionary?   Surely the aggrieved parties are in a better position to make such claims, than third parties purporting to speak on their behalf without supporting evidence. > >>> More broadly, the burden of proof should be on those demanding potentially disruptive changes, not on those who have long experience with consensus-based decision making in IETF. >> I don't think draft-knodel-terminology asks for disruptive changes, it asks for voluntary removal of exclusionary language of new RFCs and I-Ds. I do not see how that is disruptive. If that is disruptive, we have another kind of problem. > > I haven't read the latest version so this comment will be based on the previous version.   I mostly agree that the specific changes mentioned in the previous draft are uncontroversial unlikely to be disruptive. > > The problem as I see it is that bring up the subject invites some people to try to find as many words as possible to exclude from the language, and some of those suggestions are controversial. > >> As mentioned, other communities have made this commitment and I have not seen any case of disruption. But feel free to point us to it. > > Other communities have different purposes and different rules. I don't want to dissect each community and try to analyze how each one manages its internal conflicts, or whether the narrow scope of the community afforded them some insulation from potential controversy not afforded to IETF, and gauge how predictive each community's experience would be for IETF.  We don't need to resort to dubious analogies, we have already witnessed firsthand a small taste of how this specific discussion can be disruptive to IETF. You are comparing the discussion about such measures with how they would be implemented. I do not think that's fair. The assumptions you make about the potential disruptive impact, which is the main reason for _not_ changing anything and rather erring on the side of the status quo and exclusionary language, are not very much substantiated. Neither in theory, nor in practice. > > You claim you're asking for "voluntary" removal.  But what does "voluntary" mean?   In IETF some people have the power to compel authors to edit their language, else have their work discarded or lose influence over their work (depending on IPR terms chosen by the author).   So in the context of IETF the question of censorship inherently comes up, and it's certainly not a surprise that censorship is a controversial topic. Again, I don't think there is any reason to believe this would be the case. But any evidence for this would be very much appreciated. What we are currently doing is excluding people from the conversation - we only have to look at the composition of our community to confirm that. > > This is a Pandora's box, or a can of worms - pick whatever analogy you wish.   It's something that has a large potential for undesirable unintended consequences. > > But anticipating and managing potential unintended consequences is a big part of what engineers do.   So please don't fault us for trying to do that.   Sure. It just seems you're just optimizing a system based on assumptions rather than actual data and observations, which does not seem very scientific or efficient. > Some of us are just trying to figure out how to manage the occasional disruptive corner cases that we believe, based on our experiences, are likely to crop up if we move in the direction you want us to move.  Could you please document those experiences (cases) where you (or others) have been 'censored' citing the usage of exclusionary language? > My personal sense is that most of what you want is uncontroversial and that there's a likelihood of earning consensus IFF measures to limit the potential for disruption can be agreed on. I do hope so. Best, Niels > > Keith > > -- Niels ten Oever Researcher and PhD Candidate - DATACTIVE Research Group - University of Amsterdam Postdoctoral Scholar (abd) - Communications Department - Texas A&M University Research Fellow - Centre for Internet and Human Rights - European University Viadrina Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas W: https://nielstenoever.net E: mail@nielstenoever.net T: @nielstenoever P/S/WA: +31629051853 PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Thu Aug 27 03:35:00 2020 Return-Path: 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 9E2793A0A40 for ; Thu, 27 Aug 2020 03:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 3LbuYOgTTgZp for ; Thu, 27 Aug 2020 03:34:57 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A55F3A09F6 for ; Thu, 27 Aug 2020 03:34:57 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 93883F9E for ; Thu, 27 Aug 2020 06:34:56 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 27 Aug 2020 06:34:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=hnW7cdfJaO3gxtAVQ5BcTUmsR1CnGPM6DER1AwJ/R Iw=; b=YcCQbRpB0g3/ag25eeMUTlf3+T/73x8YPKUvFwuRG3z0GPGOOLcdb4qVf fOyM7d5US/sQAlraC8TFrBEdnKfA/5IuIEgE5hzgUwuZhDpQ2CqUxLWK8SSfh7YT DeatQHYiiJmbagtreaeWVRQcp2gIIuhEOFsFpYUCj3ac2Uo/BZcJTaidZ2sMzbUA /CpSF+U/sAcJ27sKhOcw5Odav+Xvtdc/cjWf11nuw+ZZMGiZ8t+bljhGKrPhRXZq 8hY3n2K1sXnvyW0IPjYSpG149nb5MBFNBUSaUJP6XcnlxdCzd365gnel2HOkErge 5ePmrsc9R1mQwAGGIDEoXP11gDlWw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvgedgvdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtke ertddtfeejnecuhfhrohhmpefmvghithhhucfoohhorhgvuceomhhoohhrvgesnhgvthif ohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenucggtffrrghtthgvrhhnpeehhfeutdehfe fgfefghfekhefguefgieduueegjeekfeelleeuieffteefueduueenucfkphepuddtkedr vddvuddrudektddrudehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepmhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 929E73060067 for ; Thu, 27 Aug 2020 06:34:55 -0400 (EDT) To: gendispatch@ietf.org References: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> <9584b8b1-a4dd-5a41-ffba-93df5d780f23@network-heretics.com> From: Keith Moore Message-ID: <6f296d9f-6b5e-9caf-71f3-77467140fc1e@network-heretics.com> Date: Thu, 27 Aug 2020 06:34:53 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 10:34:59 -0000 On 8/27/20 6:31 AM, Niels ten Oever wrote: >> Other communities have different purposes and different rules. I don't want to dissect each community and try to analyze how each one manages its internal conflicts, or whether the narrow scope of the community afforded them some insulation from potential controversy not afforded to IETF, and gauge how predictive each community's experience would be for IETF.  We don't need to resort to dubious analogies, we have already witnessed firsthand a small taste of how this specific discussion can be disruptive to IETF. > You are comparing the discussion about such measures with how they would be implemented. I do not think that's fair. The assumptions you make about the potential disruptive impact, which is the main reason for _not_ changing anything and rather erring on the side of the status quo and exclusionary language, are not very much substantiated. Neither in theory, nor in practice. Well, I'm not arguing for not changing anything.  I'm arguing for changing things but with due care.    And I trust my 30-year experience in IETF over the mere assertions of someone else. Keith From nobody Thu Aug 27 03:45:09 2020 Return-Path: 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 12E993A0B6A for ; Thu, 27 Aug 2020 03:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, 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 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 kDlJe74uUk6t for ; Thu, 27 Aug 2020 03:45:05 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706893A0B56 for ; Thu, 27 Aug 2020 03:45:05 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1kBFOw-0000tr-DK for gendispatch@ietf.org; Thu, 27 Aug 2020 12:45:04 +0200 To: gendispatch@ietf.org References: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> <9584b8b1-a4dd-5a41-ffba-93df5d780f23@network-heretics.com> <6f296d9f-6b5e-9caf-71f3-77467140fc1e@network-heretics.com> From: Niels ten Oever Autocrypt: addr=lists@digitaldissidents.org; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtC1OaWVscyB0ZW4g T2V2ZXIgPGxpc3RzQGRpZ2l0YWxkaXNzaWRlbnRzLm9yZz6JAj8EEwEIACkFAlgvB3YCGyMF CQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRAO2D86RorIs56yD/44BSJvKnjH ex0nhPDI9nIJlzlnypa4qsniy0obG5GRbVRikT1E1xaz7VBoPs39hCywoIWd6p0hs1PG1Tcj WV0GwNKRt90PPEh6iNJSGjV2Aq3IlME/aUViD9008yfbRSqfsnPXLW1kpCoZNaOSNzpURoM9 OkVU/z4LSLD61SfFFByBne/GkJKt96/fcspBif1GPC//63ZKFrDqQ9JFR6dECAmsKv7baayz MTv3wrTcqpuHcqJIv4vTm8IPx1QiGgEvrMwsPZz/vx8bMdxxxHWgCcbrt+0b3tRzq9ATZwG3 xDiwnJgKd+ioZOC/b5sY69721sqwBmWYyXWVqtqt01xIgNZjr/wixam+l1bTGUgj0rwPWJWx +7Whe25ff+mNNW/UQeCBjZlxoxAJWSr1Pp3n+SQKQ4TLs8wIwHZtcVCffepfHd47CEbnR8Kc Tjm3tlKzSWq4zcUy6BaxHfgn9+HaAM7fwLqx9/WAtSfdmLXJTN+Swy0w/slakD75jl2o7U3e ETjoYQWt+306X2Uly/0ge7VEQ4ySmmbru6U5ainGE95gjsc++s+hvKmMuGYL3h4ijE1RSe/k wgM6/Z1B6JosssdX+KRuuk2A4FHGbcee8LUIJ3C36qyI7s6PJBXi6SjIPN0wpx30P/DUf/Lr o5lmHF03qQ5eeqI8lDwIobWlJbkCDQRYKXEdARAAxYOE3/AFmEfQ0SVVFujYFhZKX+BGXolY ytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fxj+uXvLKAm9xQRI/DCug7/NGULMk9 bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHwyIawsSCN9AhDXZQWVRqkR1QXcq3I YKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVOBR8xUCBbyk5aRW4VSGO6pUD3H21u r+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8ITaNdFSAttkdT56wAQpxE2h8zaOmBa FUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZtPP9gIX+ic8QO5iuct37bRXJU/rm rH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJHE8JMaX0yYT6h4PGRS3mNM4bka8hj dfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCVaTfJLFPEru3drxNwi6ogdkRmcLGK qqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+uPlDtuExehLsNOMpjP8qhZpFtyLe DS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwODyVwk3MK5Em4pJ0+IAJx+F6gta0B k2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAKCRAO2D86RorIs0ykD/4t151SZG9M beKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvbgB4CtkBuXQlq+plOBWv+rFEThOzy 3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK83OGnfM02qP1Ky8d7EoZz+nTSMf/ DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9Oy1wWy6fHjwx3r+wQSokBNfxgQyAF onmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDvLwOUYKevBIeJJcqTyfAn3TtJbPCE HOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWvKKmBNBB5OJ/rmHogbNU+wWPJ723q MBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiGpWv4tMc5oB/qVh3my1VO65ErcJ3S 9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJBX6jeYZabGvnTicQlBAzfGpblFqV 3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0OhbnytnopKJKk99bwMoCqDkfQvT3 LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ9DYmtE40zO6g70VVxUj+dKt2hbJT y/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <1cdb07cf-4cd5-7f29-3c2c-78bb086e1816@digitaldissidents.org> Date: Thu, 27 Aug 2020 12:45:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <6f296d9f-6b5e-9caf-71f3-77467140fc1e@network-heretics.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: 29cc722430e8f1f6ed904119444c0d49b0f3ee91 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 2ecd0b53b7de9511489f92806276a3d7 Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 10:45:08 -0000 Dear Keith, On 8/27/20 12:34 PM, Keith Moore wrote: > On 8/27/20 6:31 AM, Niels ten Oever wrote: > >>> Other communities have different purposes and different rules. I don't want to dissect each community and try to analyze how each one manages its internal conflicts, or whether the narrow scope of the community afforded them some insulation from potential controversy not afforded to IETF, and gauge how predictive each community's experience would be for IETF.  We don't need to resort to dubious analogies, we have already witnessed firsthand a small taste of how this specific discussion can be disruptive to IETF. >> You are comparing the discussion about such measures with how they would be implemented. I do not think that's fair. The assumptions you make about the potential disruptive impact, which is the main reason for _not_ changing anything and rather erring on the side of the status quo and exclusionary language, are not very much substantiated. Neither in theory, nor in practice. > > Well, I'm not arguing for not changing anything.  I'm arguing for changing things but with due care.    And I trust my 30-year experience in IETF over the mere assertions of someone else. > The problem is, I am not making assertions. The whole of draft-knodel-terminology has been based on research. Whereas draft-moore-exclusionary-language and draft-gondwana-effective-terminology do not back up their claims with literature or data. That does not seem a very scientific or engineering way to go about it to me. But of course, happy to discuss. Best, Niels > Keith > > -- Niels ten Oever Researcher and PhD Candidate - DATACTIVE Research Group - University of Amsterdam Postdoctoral Scholar (abd) - Communications Department - Texas A&M University Research Fellow - Centre for Internet and Human Rights - European University Viadrina Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas W: https://nielstenoever.net E: mail@nielstenoever.net T: @nielstenoever P/S/WA: +31629051853 PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Thu Aug 27 04:58:13 2020 Return-Path: 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 9FED23A0C19 for ; Thu, 27 Aug 2020 04:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 3XTXqpvc4fmZ for ; Thu, 27 Aug 2020 04:58:11 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD6C3A0C13 for ; Thu, 27 Aug 2020 04:58:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4697; q=dns/txt; s=iport; t=1598529490; x=1599739090; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=6UbCHAzSL2VXyLamCGxcDQs9jG10ATtGAJVaefsiUoE=; b=U+f6urdWfY7YreQoSDUUCx4RBvw5CxSlG1P9yCMvq41os1A4cv64nTJP ZwaXbIvMDwlCRXDnX7fcuxI2HmtBtPqHY0EmAejH5AllZJhiO3icDEhjd BpHozyFZ6Cz1lkL8Knuyr1D/o2S16ykmlx1+4qIfykqFzgooP+WCY/ena A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APBADynkdf/xbLJq1gHQEBAQEJARI?= =?us-ascii?q?BBQUBggqDbgEyLIQ3iQGIMpQDiBkLAQEBDAEBGAEWBAEBhEwCgkQlOBMCAwE?= =?us-ascii?q?BCwEBBQEBAQIBBgRthWiFcgEBAQMBARcLVgULCwQUKgICKC8GE4Mmgl0gsVd?= =?us-ascii?q?2gTKFU4UggTiNQIIAgTgcgh8uPoQUg0Azgi0EmhycPIJtgwyQVYZMAx6ReY5?= =?us-ascii?q?Mrj+DWAIEBgUCFYFrIyqBLTMaCBsVZQGCPj4SGQ2OKxeOJj8DMDcCBgEJAQE?= =?us-ascii?q?DCY4bgkYBAQ?= X-IronPort-AV: E=Sophos; i="5.76,359,1592870400"; d="scan'208,217"; a="29047848" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Aug 2020 11:58:06 +0000 Received: from [10.61.210.152] ([10.61.210.152]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 07RBw48d016094 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Aug 2020 11:58:06 GMT From: Eliot Lear Message-Id: <8DDD735F-6FF7-47BF-BD13-66423BB1934C@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1B8DA97E-2C04-41AC-A3C6-E13892A2E8D5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Thu, 27 Aug 2020 13:58:04 +0200 In-Reply-To: <1cdb07cf-4cd5-7f29-3c2c-78bb086e1816@digitaldissidents.org> Cc: gendispatch@ietf.org To: Niels ten Oever References: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> <9584b8b1-a4dd-5a41-ffba-93df5d780f23@network-heretics.com> <6f296d9f-6b5e-9caf-71f3-77467140fc1e@network-heretics.com> <1cdb07cf-4cd5-7f29-3c2c-78bb086e1816@digitaldissidents.org> X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.210.152, [10.61.210.152] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 11:58:13 -0000 --Apple-Mail=_1B8DA97E-2C04-41AC-A3C6-E13892A2E8D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Let me prefix my comments that I am not a linguist, an anthropologist, a = sociologist, a neurologist, a philosopher (except on the net ;-), or a = psychologist. My ability to survey the literature in this space is = limited. This having been said... > On 27 Aug 2020, at 12:45, Niels ten Oever = wrote: >=20 > The problem is, I am not making assertions. The whole of = draft-knodel-terminology has been based on research. This requires some teasing out. I enjoyed reading about Lakoff and = Wyatt in your draft, and I will take as axiomatic your statements from = Burgest. =20 However, I take exception to how you and others have used Eglash. What = he published was an essay (an enjoyable one at that), and if one were to = call it research, it would be of the most informal, unscientific kind, = which he himself noted (which I thoroughly appreciate). It is = particularly important that you cite his work in this light because his = name is being bantered about across the Internet, as is your draft, as = if what he wrote was in some way dispository, which cannot in any way be = claimed. I am not claiming his conclusions are wrong; I am not qualified to do = so; I merely claim that you and others need to place them into a proper = context. And so... > Whereas draft-moore-exclusionary-language and = draft-gondwana-effective-terminology do not back up their claims with = literature or data. That does not seem a very scientific or engineering = way to go about it to me. But of course, happy to discuss.=20 Before you pursue that line, I think it=E2=80=99s important that you = address the point I made. Eliot --Apple-Mail=_1B8DA97E-2C04-41AC-A3C6-E13892A2E8D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi

Let me prefix my comments that I am not a linguist, an = anthropologist, a sociologist, a neurologist, a philosopher (except on = the net ;-), or a psychologist.  My ability to survey the = literature in this space is limited.  This having been = said...

On 27 Aug 2020, at 12:45, Niels ten Oever <lists@digitaldissidents.org> wrote:

The problem is, I am not = making assertions. The whole of draft-knodel-terminology has been based = on research.

This = requires some teasing out.    I enjoyed reading about Lakoff = and Wyatt in your draft, and I will take as axiomatic your statements = from Burgest.  

However, I take = exception to how you and others have used Eglash.  What he = published was an essay (an enjoyable one at that), and = if one were to call it research, it would be of the most informal, = unscientific kind, which he himself noted (which I thoroughly = appreciate).  It is particularly important that you cite his work = in this light because his name is being bantered about across the = Internet, as is your draft, as if what he wrote was in some way = dispository, which cannot in any way be claimed.

I am not claiming his conclusions are wrong; I am = not qualified to do so; I merely claim that you and others need to place = them into a proper context.

And = so...

Whereas draft-moore-exclusionary-language and = draft-gondwana-effective-terminology do not back up their claims with = literature or data. That does not seem a very scientific or engineering = way to go about it to me. But of course, happy to discuss.

Before you = pursue that line, I think it=E2=80=99s important that you address the = point I made.

Eliot

= --Apple-Mail=_1B8DA97E-2C04-41AC-A3C6-E13892A2E8D5-- From nobody Thu Aug 27 05:04:28 2020 Return-Path: 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 A24993A0C2E for ; Thu, 27 Aug 2020 05:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, 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 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 7kvQX_3iIvWp for ; Thu, 27 Aug 2020 05:04:24 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8C83A0C28 for ; Thu, 27 Aug 2020 05:04:22 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1kBGdd-0001sd-Ie; Thu, 27 Aug 2020 14:04:19 +0200 To: Eliot Lear Cc: gendispatch@ietf.org References: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> <9584b8b1-a4dd-5a41-ffba-93df5d780f23@network-heretics.com> <6f296d9f-6b5e-9caf-71f3-77467140fc1e@network-heretics.com> <1cdb07cf-4cd5-7f29-3c2c-78bb086e1816@digitaldissidents.org> <8DDD735F-6FF7-47BF-BD13-66423BB1934C@cisco.com> From: Niels ten Oever Autocrypt: addr=lists@digitaldissidents.org; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtC1OaWVscyB0ZW4g T2V2ZXIgPGxpc3RzQGRpZ2l0YWxkaXNzaWRlbnRzLm9yZz6JAj8EEwEIACkFAlgvB3YCGyMF CQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRAO2D86RorIs56yD/44BSJvKnjH ex0nhPDI9nIJlzlnypa4qsniy0obG5GRbVRikT1E1xaz7VBoPs39hCywoIWd6p0hs1PG1Tcj WV0GwNKRt90PPEh6iNJSGjV2Aq3IlME/aUViD9008yfbRSqfsnPXLW1kpCoZNaOSNzpURoM9 OkVU/z4LSLD61SfFFByBne/GkJKt96/fcspBif1GPC//63ZKFrDqQ9JFR6dECAmsKv7baayz MTv3wrTcqpuHcqJIv4vTm8IPx1QiGgEvrMwsPZz/vx8bMdxxxHWgCcbrt+0b3tRzq9ATZwG3 xDiwnJgKd+ioZOC/b5sY69721sqwBmWYyXWVqtqt01xIgNZjr/wixam+l1bTGUgj0rwPWJWx +7Whe25ff+mNNW/UQeCBjZlxoxAJWSr1Pp3n+SQKQ4TLs8wIwHZtcVCffepfHd47CEbnR8Kc Tjm3tlKzSWq4zcUy6BaxHfgn9+HaAM7fwLqx9/WAtSfdmLXJTN+Swy0w/slakD75jl2o7U3e ETjoYQWt+306X2Uly/0ge7VEQ4ySmmbru6U5ainGE95gjsc++s+hvKmMuGYL3h4ijE1RSe/k wgM6/Z1B6JosssdX+KRuuk2A4FHGbcee8LUIJ3C36qyI7s6PJBXi6SjIPN0wpx30P/DUf/Lr o5lmHF03qQ5eeqI8lDwIobWlJbkCDQRYKXEdARAAxYOE3/AFmEfQ0SVVFujYFhZKX+BGXolY ytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fxj+uXvLKAm9xQRI/DCug7/NGULMk9 bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHwyIawsSCN9AhDXZQWVRqkR1QXcq3I YKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVOBR8xUCBbyk5aRW4VSGO6pUD3H21u r+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8ITaNdFSAttkdT56wAQpxE2h8zaOmBa FUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZtPP9gIX+ic8QO5iuct37bRXJU/rm rH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJHE8JMaX0yYT6h4PGRS3mNM4bka8hj dfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCVaTfJLFPEru3drxNwi6ogdkRmcLGK qqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+uPlDtuExehLsNOMpjP8qhZpFtyLe DS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwODyVwk3MK5Em4pJ0+IAJx+F6gta0B k2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAKCRAO2D86RorIs0ykD/4t151SZG9M beKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvbgB4CtkBuXQlq+plOBWv+rFEThOzy 3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK83OGnfM02qP1Ky8d7EoZz+nTSMf/ DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9Oy1wWy6fHjwx3r+wQSokBNfxgQyAF onmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDvLwOUYKevBIeJJcqTyfAn3TtJbPCE HOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWvKKmBNBB5OJ/rmHogbNU+wWPJ723q MBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiGpWv4tMc5oB/qVh3my1VO65ErcJ3S 9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJBX6jeYZabGvnTicQlBAzfGpblFqV 3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0OhbnytnopKJKk99bwMoCqDkfQvT3 LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ9DYmtE40zO6g70VVxUj+dKt2hbJT y/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <646e3c5c-08cb-5e2d-0e96-4e7c7bee8d4a@digitaldissidents.org> Date: Thu, 27 Aug 2020 14:04:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <8DDD735F-6FF7-47BF-BD13-66423BB1934C@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: 29cc722430e8f1f6ed904119444c0d49b0f3ee91 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: a2d32f98be707cbcda8602d5fffa976a Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 12:04:27 -0000 On 8/27/20 1:58 PM, Eliot Lear wrote: > Hi > > Let me prefix my comments that I am not a linguist, an anthropologist, a sociologist, a neurologist, a philosopher (except on the net ;-), or a psychologist.  My ability to survey the literature in this space is limited.  This having been said... > >> On 27 Aug 2020, at 12:45, Niels ten Oever > wrote: >> >> The problem is, I am not making assertions. The whole of draft-knodel-terminology has been based on research. > > This requires some teasing out.    I enjoyed reading about Lakoff and Wyatt in your draft, and I will take as axiomatic your statements from Burgest.   > > However, I take exception to how you and others have used Eglash.  What he published was an *essay* (an enjoyable one at that), and if one were to call it research, it would be of the most informal, unscientific kind, which he himself noted (which I thoroughly appreciate).  It is particularly important that you cite his work in this light because his name is being bantered about across the Internet, as is your draft, as if what he wrote was in some way dispository, which cannot in any way be claimed. > > I am not claiming his conclusions are wrong; I am not qualified to do so; I merely claim that you and others need to place them into a proper context. > > And so... > >> Whereas draft-moore-exclusionary-language and draft-gondwana-effective-terminology do not back up their claims with literature or data. That does not seem a very scientific or engineering way to go about it to me. But of course, happy to discuss. > > Before you pursue that line, I think it’s important that you address the point I made. Thank you very much Eliot, could you also review the other drafts through the same critical lens? Much appreciated. Best, Niels > > Eliot > -- Niels ten Oever Researcher and PhD Candidate - DATACTIVE Research Group - University of Amsterdam Postdoctoral Scholar (abd) - Communications Department - Texas A&M University Research Fellow - Centre for Internet and Human Rights - European University Viadrina Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas W: https://nielstenoever.net E: mail@nielstenoever.net T: @nielstenoever P/S/WA: +31629051853 PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Thu Aug 27 05:09:48 2020 Return-Path: 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 1FF3D3A0C4D for ; Thu, 27 Aug 2020 05:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 3Y_QhWXfriHw for ; Thu, 27 Aug 2020 05:09:46 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 985863A0C4C for ; Thu, 27 Aug 2020 05:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=378; q=dns/txt; s=iport; t=1598530185; x=1599739785; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=yvn0+sCwbIWO0LQTlwAr4UCwqf17cfuMl++Fg342OYs=; b=R065rYfST0cv7cQB9wcaSIDBKYAhHMgpSZxMuas9lhIvdSoGkN0dch49 oxKbvEWkwOlxioT63EccZ1r07Evu9bDABspI0CA+Qjhc4k/pV41xvX4Oe zrnki8srNv3lqnlLzEHCaJgTzJV+2AQ/vTjsWtNZMvRibpv7jQEv9Ke9e c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AuBgAbokdf/xbLJq1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqDbgEyLIQ3iQGIDCWQNotmCwEBAQwBARgXBAEBhEwCgkQ?= =?us-ascii?q?lOBMCAwEBCwEBBQEBAQIBBgRthWiFcgEBAQMBASJWBQsLGAICJgICKC8GE4M?= =?us-ascii?q?mgl0gsUZ2gTKFU4UQgQ4qjUCCAIE4DBCCHy4+hD2DFzOCLQS2WIJtgwyQVYZ?= =?us-ascii?q?MAx6CdQGPA45Mrj+DWAIEBgUCFYFrI4FXMxoIGxVlAYI+PhIZDZxoPwMwNwI?= =?us-ascii?q?GAQkBAQMJkGEBAQ?= X-IronPort-AV: E=Sophos;i="5.76,359,1592870400"; d="scan'208";a="29107898" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Aug 2020 12:09:41 +0000 Received: from [10.61.210.152] ([10.61.210.152]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 07RC9fid020544 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Aug 2020 12:09:41 GMT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Eliot Lear In-Reply-To: <646e3c5c-08cb-5e2d-0e96-4e7c7bee8d4a@digitaldissidents.org> Date: Thu, 27 Aug 2020 14:09:40 +0200 Cc: gendispatch@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <67118727-0B4D-4E1E-8C2D-2E3D39328779@cisco.com> References: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> <9584b8b1-a4dd-5a41-ffba-93df5d780f23@network-heretics.com> <6f296d9f-6b5e-9caf-71f3-77467140fc1e@network-heretics.com> <1cdb07cf-4cd5-7f29-3c2c-78bb086e1816@digitaldissidents.org> <8DDD735F-6FF7-47BF-BD13-66423BB1934C@cisco.com> <646e3c5c-08cb-5e2d-0e96-4e7c7bee8d4a@digitaldissidents.org> To: Niels ten Oever X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Outbound-SMTP-Client: 10.61.210.152, [10.61.210.152] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 12:09:47 -0000 > On 27 Aug 2020, at 14:04, Niels ten Oever = wrote: >>=20 >> Before you pursue that line, I think it=E2=80=99s important that you = address the point I made. >=20 > Thank you very much Eliot, could you also review the other drafts = through the same critical lens? Much appreciated. Of course. Nobody gets a free ride ;-) Eliot From nobody Thu Aug 27 06:24:31 2020 Return-Path: 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 AC33D3A08D7 for ; Thu, 27 Aug 2020 06:24:29 -0700 (PDT) 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=z7iW7Rdt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Q6m7MCfY 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 RRecY0_FgSDh for ; Thu, 27 Aug 2020 06:24:27 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862283A08CF for ; Thu, 27 Aug 2020 06:24:26 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B655C5C02E6 for ; Thu, 27 Aug 2020 09:24:25 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Thu, 27 Aug 2020 09:24:25 -0400 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:subject:content-type; s=fm3; bh=VoScyRV rYdSJxX80/73yRAZ6uTMNxELhIKuEPJUZt+s=; b=z7iW7Rdtg/N9s9Frju6mos6 eO/DB5kHEXXR77YdsBhm19+/nft3Pkw73OdNgmuDHfZTXRsjidqbiqWzFGwf+D+z GX6ea/cbErDQgLGQYhdBzFOjm/JvOKZgY5kBPaL2KSPZf9KvW9svdOFbEI4RC36L XMCIHup89P6xz1ZDsrho2l5AEtbvX2yOEJs7aDLVR8GTE/C0nGZW/4Eo1+BVZim2 s0V4Fodr76UoQFqoP7C+MbVKIWqi3M320v6StO0iitAHpb8jquWoHhhMa4R/WZH3 cAcdImo2Bf4xXbpJY8OlirTiZfUhayQy11R5HSDQVCMSYu+Lvdva/Jj5GaIdS6w= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=fm3; bh=VoScyR VrYdSJxX80/73yRAZ6uTMNxELhIKuEPJUZt+s=; b=Q6m7MCfYuwcbloJ5/Ow7Bg hY35u4UwzevGmBManRoYPjpcbCIoxgacPlSm4oHSfxBna0EcIpKPbzIpGSzURwVh DasGnYiXJhmJ9AghQqeGnLVCrSfkZ5FXZ3lAiJ5W8gnt2OV6S8/uiUBFNsK74IpB BtFEsGqq+E9b5NkQQMbvgF0SaP+W7FhqFgbqwB0/FxxZi43N3g3caV5es4Y9JNqq DKWodvE4Z2s4iwYMbdXqckP9PP8VXMRCF78PAhN/E0weUEDlvxOb55TNImAZneJx VRBjdfn9BjDuFyOr5g0CXK9twsximoDzSquzyyhTmj9/3j18AsAPSzCy6bt55gXQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvgedgieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpedvudeuieehgf dvheeuueejjeeuudfgiefgveetfeelteeffffgtdejjefgueduvdenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegsrhhonhhgsehfrghsthhmrg hilhhtvggrmhdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 28369180137; Thu, 27 Aug 2020 09:24:25 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-232-g4bdb081-fm-20200825.002-g4bdb081a Mime-Version: 1.0 Message-Id: <3207b348-e7bc-4438-bae6-b702d3bff239@dogfood.fastmail.com> In-Reply-To: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> References: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> Date: Thu, 27 Aug 2020 23:24:04 +1000 From: "Bron Gondwana" To: gendispatch@ietf.org Content-Type: multipart/alternative; boundary=16c40891fc2741d3ac445cbbae6e46f9 Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 13:24:30 -0000 --16c40891fc2741d3ac445cbbae6e46f9 Content-Type: text/plain On Thu, Aug 27, 2020, at 18:54, Niels ten Oever wrote: > Both drafts also seem to find it very important that if there is a (perceived) issue, this should be extensively documented with evidence in the form of citations and numbers. That's a very interesting reading of my draft. That was not my intent, so I'd be interested in feedback about how my language failed to communicate my intent to you. My entire intent was to remove the need to provide citations and numbers, because neither "party" as such has been able to do so, instead stating assumptions as fact. I shall try a couple of of citations now from this very thread: *"It has been proven time and again that less diverse communities produce lesser quality work than diverse communities. See also RFC7704 and a wide range of academic literature on this topic"* -- *"What we are currently doing is excluding people from the conversation - we only have to look at the composition of our community to confirm that."* -- I believe there's a logical point you a trying to make here with these two messages, and I'll paraphrase it - please let me know if you disagree. *"If we adopt draft-knodel-terminology that will lead to increased diversity in the IETF, and hence produce higher quality work".* -- me, paraphrasing the above I don't believe there is disagreement on that sentiment, merely on the terminology used to state it, the effectiveness of any particular policy prescription, and whether we should be centering the mission of the IETF, or centering current political hot-button issues. Having read Keith's draft, both he and I were careful to say that outside consensus already comes in to the IETF quite effectively and any failure there is a bug which should be fixed. Indeed, I went further and said that we should be mindful of emerging consensus and try to avoid using new terms which are likely to cause issues in the future due to the long lifetime of our documents. I think you and I are coming to the same place that increasing diversity is good, but I'm putting the priority on the IETF's needs, not the needs of currently non-contributers to the IETF who we believe we will be attracted if we only remove this one impediment. Regarding the specific issue of the request to cite work supporting the underlying position - I cite the 50 year history of the IETF and the high esteem in which our work is held - high enough that we're clearly meeting our mission effectively, even if not perfectly. ... I think we're almost entirely quibbling over semantics and approach here, but they do matter. I'm going to quote from my slides and riff on what I'm planning to say next week: *There are three ways to reach consensus: Persuasion, Fatigue and Fiat. * This topic could do a lot of damage before we reach Fatigue of all participants! A lot of the response to the IESG statement was a fear that I would paraphrase as:* consensus will be declared by fiat, because "this topic is too important, and is clearly morally right, so objection to policy provisions that claim to further its goals is inherently racist and can be dismissed". * I don't know how well founded that fear is - I hope not at all - but that fear is what I saw in the reactivity of that email thread. So... my goal was to try to document the bit where existing consensus is, and find a way to persuade, using wording which - as John Levine said - speaks to its readers as peers. I hope to discuss my draft next week with all comers and see how good my persuasive skills are! Regards, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --16c40891fc2741d3ac445cbbae6e46f9 Content-Type: text/html Content-Transfer-Encoding: quoted-printable


On Thu, Aug 27, 2020, at 18:54, Niels ten Oever wrote:
Both drafts also seem to find it very important that if there is = a (perceived) issue, this should be extensively documented with evidence= in the form of citations and numbers.

That's = a very interesting reading of my draft. That was not my intent, so I'd b= e interested in feedback about how my language failed to communicate my = intent to you.

My entire intent was to remove the need to= provide citations and numbers, because neither "party" as such has been= able to do so, instead stating assumptions as fact.

I sh= all try a couple of of citations now from this very thread:

"It has been proven time and again that less diverse communities p= roduce lesser quality work than diverse communities. See also RFC7704 an= d a wide range of academic literature on this topic" -- <ba47f01e-b2ef-591f-97d9-71964e0a6848@digitaldissidents.org>

"What we are currently doing is excluding people from th= e conversation - we only have to look at the composition of our communit= y to confirm that." -- <d5c813f3-84c2-e26f-8771-b96eb771519= 4@digitaldissidents.org>

I believe there's a logic= al point you a trying to make here with these two messages, and I'll par= aphrase it - please let me know if you disagree.

"If w= e adopt draft-knodel-terminology that will lead to increased divers= ity in the IETF, and hence produce higher quality work". -- me, para= phrasing the above

=
I don't believe there is disagreement = on that sentiment, merely on the terminology used to state it, the effec= tiveness of any particular policy prescription, and whether we should be= centering the mission of the IETF, or centering current political hot-b= utton issues.

Having read Keith's draft, both he and I we= re careful to say that outside consensus already comes in to the IETF qu= ite effectively and any failure there is a bug which should be fixed.&nb= sp; Indeed, I went further and said that we should be mindful of emergin= g consensus and try to avoid using new terms which are likely to cause i= ssues in the future due to the long lifetime of our documents.
=

I think you and I are coming to the same place that increasing div= ersity is good, but I'm putting the priority on the IETF's needs, not th= e needs of currently non-contributers to the IETF who we believe we will= be attracted if we only remove this one impediment.

Rega= rding the specific issue of the request to cite work supporting the unde= rlying position - I cite the 50 year history of the IETF and the high es= teem in which our work is held - high enough that we're clearly meeting = our mission effectively, even if not perfectly.

...

I think we're almost entirely quibbling over semantics and app= roach here, but they do matter.  I'm going to quote from my slides = and riff on what I'm planning to say next week:

There = are three ways to reach consensus: Persuasion, Fatigue and Fiat.  <= /b>

This topic could do a lot of damage before we reach F= atigue of all participants!
<= br>
A lot of the response to the = IESG statement was a fear that I would paraphrase as: consensus = will be declared by fiat, because "this topic is too important, and <= position> is clearly morally right, so objection to policy provisions= that claim to further its goals is inherently racist and can be dismiss= ed".  I don't know how well founded that fear is - I hope not a= t all - but that fear is what I saw in the reactivity of that email thre= ad.

So... my goal was to try to document the bit where ex= isting consensus is, and find a way to persuade, using wording which - a= s John Levine said - speaks to its readers as peers.  I hope to dis= cuss my draft next week with all comers and see how good my persuasive s= kills are!

Regards,

Bron.

--
=
  Bron Gondwana, CEO, Fastmail Pty Ltd
  br= ong@fastmailteam.com


--16c40891fc2741d3ac445cbbae6e46f9-- From nobody Thu Aug 27 07:56:38 2020 Return-Path: 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 BE1993A0E48 for ; Thu, 27 Aug 2020 07:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=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=comcast.com header.b=0Z6PUZYx; dkim=pass (2048-bit key) header.d=comcast.com header.b=5NlGIFfv; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=ZZ1Ka2BQ 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 xIXJ7UBSoR_A for ; Thu, 27 Aug 2020 07:56:32 -0700 (PDT) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44023A0E45 for ; Thu, 27 Aug 2020 07:56:32 -0700 (PDT) Received: from pps.filterd (m0184894.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07REsZgf025329 for ; Thu, 27 Aug 2020 10:56:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=F3Hry2XX3xA003n9vfrp8viCPThiuXFomSAqwpN3Q8A=; b=0Z6PUZYxA+ylPMLGNFkEW/YuligqSIqAEaqCYo0vxsRT+E00doAxDRIjwzrErO7u/yCM 4egKPDJ+ZM8zeK0CLJZOidOxb+EmdGbWlR/Xm7Gf583fjVsniR771AVrikecF7bxb0eq ObrACvMy1htUUUpMKJCBQXi5HbJt8jTdKyin9SgYvp0turpN93rao6MsU5Ijx8pABrZC 7IeYM7YnYOw5cesKqBTmbPXkxLvI+4sRuiukvDqnLnu9EkvCKzeWmkFfHQV4t9k/k5lT XTp12XdORmdtypyfwX3H7X5vJhgh08aQKcDY6wWxoy24l5KNGJX6u1fSWDddZaHUnGwt ew== Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0a-00143702.pphosted.com with ESMTP id 332vnwbjbc-51 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 27 Aug 2020 10:56:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1598540191; x=2462453791; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=F3Hry2XX3xA003n9vfrp8viCPThiuXFomSAqwpN3Q8A=; b=5NlGIFfvsxpd45KFiphdEPdM4hqOH2p+SHqfDKRPCJXXGlNpsQO9DBB8Ybc3LGQp wt5WYzr0b6vVer1mR+1/pvrT3VJo4jqKT9dA14gGY1ieURIjdcb1U27XSdupMSyn VdE/wTu3RoicGMsPVmBwvrgJyGEX0GazIN9++RdU2I2illN70m5gg1IvhzpVN1Sk 7NID8DjpBoX3iGbHSiZs8DEwmWE5IwZq6X9OvtrXUfGDxvR1ZB4JaoXcjIB+PI9+ hx86ku7YVqYB5o2bm+1eQfoawpmn4XJCcfoWV/SlCE/rDT/5YKI8irxaAAn2HySo jax+uaIIhw5b4q5RHWTqPw==; X-AuditID: 60729ed4-a49ff70000003048-92-5f47c99fbdf4 Received: from COPDCEX14.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 76.69.12360.F99C74F5; Thu, 27 Aug 2020 08:56:31 -0600 (MDT) Received: from COPDCEX13.cable.comcast.com (147.191.124.144) by COPDCEX14.cable.comcast.com (147.191.124.145) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Aug 2020 08:56:30 -0600 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX13.cable.comcast.com (147.191.124.144) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 27 Aug 2020 08:56:30 -0600 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.175) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Aug 2020 10:56:19 -0400 Received: from MN2PR11MB4287.namprd11.prod.outlook.com (2603:10b6:208:189::17) by MN2PR11MB4238.namprd11.prod.outlook.com (2603:10b6:208:188::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.26; Thu, 27 Aug 2020 14:56:16 +0000 Received: from MN2PR11MB4287.namprd11.prod.outlook.com ([fe80::b951:e489:324b:cb3f]) by MN2PR11MB4287.namprd11.prod.outlook.com ([fe80::b951:e489:324b:cb3f%6]) with mapi id 15.20.3305.032; Thu, 27 Aug 2020 14:56:15 +0000 From: "Livingood, Jason" To: Keith Moore , "gendispatch@ietf.org" Thread-Topic: [Gendispatch] Grounding the exclusionary language discussion Thread-Index: AQHWfE+1h05Ww0QqwEekroA7vDf6YKlLqyWAgAAdmYA= Date: Thu, 27 Aug 2020 14:56:15 +0000 Message-ID: <8BD7761E-0DD0-4B1B-88FD-51FD5DAE3683@cable.comcast.com> References: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: network-heretics.com; dkim=none (message not signed) header.d=none;network-heretics.com; dmarc=none action=none header.from=cable.comcast.com; x-originating-ip: [2601:87:4280:7190:34a9:157:896e:48fa] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 21a7477e-37d0-4b3b-381d-08d84a995925 x-ms-traffictypediagnostic: MN2PR11MB4238: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4303; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Y+EcDxVnKJ170v+1o4J3xWfAtCJ7wTkJz2A/HM0k6Mbi+lOWc1IgOC1SsMFvdkJHfDRD/xRm/DnZEz/SDvi+kjgry/uoLXbMgCEvTQE49MHA616b9onWPZrKB2gohr/x0fYN4jmxTunISlb8KjYv/SVarcrDfVcCEeX0JfXSLWCq56siNOHsouDnb9MJh+NdKFsgBkXTeTUCRlU51MKgo/whKP9xGFx7ToEPOSdaWjCD2dvqI+bvbdxWbLSix/U6qF0lYaQ2cwm9TUiKrnCJItrxM6a6J3CjDdGcr/Uvxkpt5cTi+HrGjd9CBc5SouD4xvbDPId9fX1w6McGOVjhIg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4287.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(39860400002)(376002)(136003)(396003)(366004)(316002)(33656002)(66946007)(8676002)(478600001)(110136005)(4744005)(186003)(2616005)(6486002)(86362001)(2906002)(71200400001)(64756008)(66446008)(8936002)(76116006)(6512007)(5660300002)(66556008)(6506007)(66476007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: +HbQXvEwXJ4DK0Srk98d0D42OcJOGHIDmw2aRvAtSMHhlAzGruw1557qZtF2/PUgDtbPi5R3mjtzu5FcMQOstyssBcYPMHS23LUDqMSJUcEGBi6oa9sSaPEgMRC0TDfWY7b4SdV7bFfYb35GqVzqh5FvXruXJmhI3gW+dZxTsCUaM1yy2bMlDdeIVbbcIKaDXC8h7QTfRV4BRs0EAFXvZlzXkOpjNPpiuWWpHyx6V6+XarJSJXtXnGJ3dAN4CdovzznbphLKx/LEwYIug7tjr1JrS2sYs73/0sMKdEd6AKylfaRF4cPc8a6JzG2L9/Tbpd1C4JOppQ4q70CT9PFO+mBdt3+cKHZ81KXbPToAisGH5wcCeqsa+JdNSETHb0Qmz1N/ncCsyr690Xc1TR2zV6gGuhHQDJ2Mqwqe1iSgZCAkMsIDNqMfYkrMEoRJu0bYnFBxW/fi4ZIygeDrX2VNrPGeb6mI/b4I538k0X21lyxcDc74u3jhMmMjMezP2clx+U2zbOBNBx07tiy/+rtl9m4FFhs0V9cQFH5mXUBUDDrNDGkecobOf7a3ViWDTmIuGqQfCOb0mIFqjy8dXzYdMvwPeKbCXxhVMRDxyN5eknLNk6irjn6nSBdpFxfQWV3gQxPyd2DqKq6r+JpwBOT4e4UpZeA3LtdJXULtLkgzaTTKDr2LewM8KF6WmbgtS9xyEfCT4DyvL5RX1U9Klxjq8w== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SyYK4TNs93hHU2Uajwe1gIbiv/FGg3wP6WX3UbwvWT7GVJN774wotuGfPu6CKut/LW7fImHns1WZnBkeh1x7EpzVjRd9qIGG40pUacIE2TcwXpPIbmkOBgjw/zZrREVaO3xt1RBjeXZvIqtMO3s9J3B0WD9AxXnM4G/qSbtpWdh5DLZT/LTpvaK6kblN7iPVSgVoAEBc7OUpR7B5MGsvD8j8ynnoEyqrUyIgyQtBbdEIscFKNGZwxsx3d++GV3drcS6HjctvHJMQDL3zI3hkXcGN6pqTfw2x/np4EWhdNsi2PglsnbStVAf8uVNoh8dfJUdrD/iEigrYgnqIwasgHQ== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KKT1aHnk10Ttp1ncfVy/0+EVdRJQlmQhFK3jGGlDgtI=; b=BqLfjtJulCVtKBhq27eJzXEbt/tLBDDu3Xkse0EJ6VLJYR0YedBS2C+KLwNzKCuWpTU7KBbbrKbpMs0QHOdAK7lHE74iRBen0m0u7V46sEZkRtkSIrGxcFe1fn5R1SA6O76la49EWZVMUqTIVdtqkRoG1r1LV3I3d2sUouwawOlanMxv92l46C9aPUTPbyAab25EEMxpya2c45B+AFN43QSxEXReHb8tXaJ63VDlsQNp7x7snq6xdamkLEs9HbPDd6wqtFE3pTwLmh8pfiz888rwglTdoEkN1wO6554XdB0JO01eOvdPQAMy2tDgAZ8Cm0juLr84UHYAdmFV8LpEHA== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KKT1aHnk10Ttp1ncfVy/0+EVdRJQlmQhFK3jGGlDgtI=; b=ZZ1Ka2BQYg4cFS30p22+mEuYBc/HuKuPNmz39i0l3FgtgM+uGGeDBeCfu5uGAS7EXhL2zW1JnFd2BuT/DWGqtJJj19/gDAhQGUZp9P25YCkLNuXwg+FhTk8XIx67qCfadTtWlcNy2w3gDA/+PpBXJ1K7EGSNVCke9v10E+9KuL8= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4287.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 21a7477e-37d0-4b3b-381d-08d84a995925 x-ms-exchange-crosstenant-originalarrivaltime: 27 Aug 2020 14:56:15.6749 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: Pzh88WOquN6qc63fJbaAd+bzKRnm6v0ky6rh1WWM8gohOD7Y2LTm93bIZS0cdAvKLzNKdwycJ4bBbiXG/MKWzuYeHacPMTDqiYsmRIDZScE= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4238 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <04028E7F7D648E48A493A4ED3EE93394@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42JJKJozWXf+Sfd4g+3X9SzmN6xgtZj09Ryb A5PHkiU/mTwmnQgLYIrisklJzcksSy3St0vgypi9+z9TwROWiuuTNrM2MF5h6WLk4JAQMJGY Ma28i5GLQ0jgMJNE69W7rBDOIUaJrat3MEE4dxglzn84xgbhnGSUeLnoGDOEs5RJYuHhyVA9 jxgl1p1vBhrMycEmYCZxd+EVZhBbRCBW4vfZl+wgtrCAp0TX37tMIMtFBLwkvj51hiixktjb 94kJxGYRUJU4/bEVrJxXwEXi362DUMvaGCVm/NsNVsQp4CGx7ss9NhCbUUBM4vupNWBxZgFx iVtP5oPZEgICEkv2nGeGsEUlXj7+xwpiiwroS7zu2An2G6PAKkaJyzNfsEEUWUjser6NHcKW lbg0v5sRwvaV2Pp/OguErQUMmJNQ8WyJN8cXQdlqEu0XVkH1ykms6n0IVS8j8eDGdnDYSQj8 ZpKYvvQpC4Szj1ni2q29bBMYTWchuXwWMGSYBTQl1u/Shwh7SHT+fsICYStKTOl+yD4LHDKC EidnPmFZwMi6ipHP0kzP0NBEz9DUQs/I0GgTIziFzLuyg/HydI9DjAIcjEo8vN573OOFWBPL iitzgZHLwawkwvv6KFCINyWxsiq1KD++qDQntfgQozQHi5I4b2zs2TghgfTEktTs1NSC1CKY LBMHp1QD4/7f9UukTSKn7Fqy+dApNam9aWcyGfW0mp6ccNjCYxu3j5OZNaz94l7ZCkvVWcrL mR5XyBaeyo+t5m+5WOpyVKCwRVfz8Ev+LQUXMrZ1ye4pDVkVn/iYJ7Fvkviyx8U1np0don63 bs9ryyt60vCkmEHhZvC3c9O3a0f9O/8mP0WlWIhvs2WkEktxRqKhFnNRcSIAYR+x9h0DAAA= X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-27_08:2020-08-27, 2020-08-27 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 14:56:37 -0000 KHBlcnNvbmFsIHZpZXdzIC0gbm8gaGF0cykNCg0K77u/T24gOC8yNy8yMCwgNToxMCBBTSwgIkdl bmRpc3BhdGNoIG9uIGJlaGFsZiBvZiBLZWl0aCBNb29yZSIgPGdlbmRpc3BhdGNoLWJvdW5jZXNA aWV0Zi5vcmcgb24gYmVoYWxmIG9mIG1vb3JlQG5ldHdvcmstaGVyZXRpY3MuY29tPiB3cm90ZToN Cg0KPiAgICBNb3JlIGJyb2FkbHksIHRoZSBidXJkZW4gb2YgcHJvb2Ygc2hvdWxkIGJlIG9uIHRo b3NlIGRlbWFuZGluZw0KICAgIHBvdGVudGlhbGx5IGRpc3J1cHRpdmUgY2hhbmdlcw0KDQpbSkxd IEknbSBub3Qgc3VyZSBob3cgYSBjaGFuZ2UgZnJvbSB0aGUgdGVybWlub2xvZ3kgb2YgbWFzdGVy LXNsYXZlIHRvIHByaW1hcnktc2Vjb25kYXJ5IGNhbiBiZSBjb25zaWRlcmVkIGRpc3J1cHRpdmUg LSBpdCBzZWVtcyBhIGxpdHRsZSBzaWxseSB0byBzdWdnZXN0IHNvLg0KDQoNCg== From nobody Thu Aug 27 08:13:22 2020 Return-Path: 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 5C3633A0DF9 for ; Thu, 27 Aug 2020 08:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 fHiTQTj8__Pv for ; Thu, 27 Aug 2020 08:13:19 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A863A0DF4 for ; Thu, 27 Aug 2020 08:13:19 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 42F275C0286; Thu, 27 Aug 2020 11:13:18 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 27 Aug 2020 11:13:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=VIzB+7jCqzy6a+4xH+kWhd93kbayoQq/KfINEEqAQ JA=; b=tjxKpt0zHJOn64nSsEZ2qGWcfuP34+NHxxSeVH63UF6pTTDunAlPQ1yYu fCv+wFM9bl007gQmFbI1mLwaSyCoSJ7vF9hyFMuzL06UH7MhR9n/2O3vu99n54eD pTBughenuw+YKkYljePWDVWCPU4nQj+iCwBTvwHtPQhlvut6D3ybYe1ZBMXcgxyj xwlM/BGIWYbB9tj1AxBZe/5rKqggozx28dkNvc15EOpgUaor3gW826UGniMkVDyg b+f4+N7ZhcNFVEdQ5o/qFmLUabAw5YkpjECB7q2/b5oGtsqZF6YI9RxAE7yZPy5P xv8gFLjldLuoIuKzApY3C+1L35F9w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvgedgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtgfesthejredttdefjeenucfhrhhomhepmfgvihht hhcuofhoohhrvgcuoehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh eqnecuggftrfgrthhtvghrnhepkedvgefgleeuleekuefhffehgefhhfekuedvudduiefh hedufefftdfgtdekfffgnecukfhppedutdekrddvvddurddukedtrdduheenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmohhorhgvsehnvght fihorhhkqdhhvghrvghtihgtshdrtghomh X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 72DE730600B1; Thu, 27 Aug 2020 11:13:17 -0400 (EDT) To: "Livingood, Jason" , "gendispatch@ietf.org" References: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> <8BD7761E-0DD0-4B1B-88FD-51FD5DAE3683@cable.comcast.com> From: Keith Moore Message-ID: <6572756a-4679-79b6-8f40-ebc2b748b2d4@network-heretics.com> Date: Thu, 27 Aug 2020 11:13:15 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <8BD7761E-0DD0-4B1B-88FD-51FD5DAE3683@cable.comcast.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 15:13:20 -0000 On 8/27/20 10:56 AM, Livingood, Jason wrote: >> More broadly, the burden of proof should be on those demanding potentially disruptive changes > > [JL] I'm not sure how a change from the terminology of master-slave to primary-secondary can be considered disruptive - it seems a little silly to suggest so. Without going into detail, I don't think I have as much confidence as you do about that. But to clarify, the potential disruption I anticipate and want to avoid would probably be due to any of: (a) interminable or repeated arguments about whether it's ok to ban or even discourage particular terms (like "master") for which there's little etomologic justification and a large potential loss in terms of readability if the term were banned; (b) the possibility of documents being arbitrarily blocked by IESG over the documents' use of certain words, without the backing of community consensus; or (c) documents held up interminably (in a WG or anywhere else) over disputes about terminology. Keith From nobody Thu Aug 27 09:15:02 2020 Return-Path: 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 84A193A101E for ; Thu, 27 Aug 2020 09:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=D0K1IJBf; dkim=pass (2048-bit key) header.d=taugh.com header.b=TiNHW+Sj 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 huA_RlpUc35b for ; Thu, 27 Aug 2020 09:14:59 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 126B83A1015 for ; Thu, 27 Aug 2020 09:14:58 -0700 (PDT) Received: (qmail 20880 invoked from network); 27 Aug 2020 16:14:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=518d.5f47dc00.k2008; bh=IaZwwOZQyrEKkKbqVnrAg7GR5Goy6gMSxgvKuzZK0QY=; b=D0K1IJBfTdbAf2FcWDIS9pEufTWSeRIsJVB6ldl751F8NeN7IBYeIOwLOdsjDd9/+Q3vQVjXcW16iYz0jcr6sc2e4Oy/JZi0aNl23xa+rQpyUHWgBz25b/Jgd5XO1Dq6VWuxfB5p+6kiwPtihxbtjbPwjTq6dnb6XD7CN3QjScJsCtHbBbuxiPY34DXZB4J79dCN96ZBWQuVdf1uVBkPKMpXt1VvAFP0JALExS546yShpvauUYwXk7Z3CxT7yRk5IWf5M29A39PgQRJjzGZ5cTR8tO6a9GVK064PhQyikz0Oes2oi0hVn4OAHINGk61x+Ng+xY3vJ1z22TVaw3To6g== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=518d.5f47dc00.k2008; bh=IaZwwOZQyrEKkKbqVnrAg7GR5Goy6gMSxgvKuzZK0QY=; b=TiNHW+SjXPrDNkRPBQqVMbE412cEUlRMKBBw8wyVAEvnJS3RsMUkXhl/XfMg6Qb0iGQHLJK2uMRtQL1SVdYy2RpfhMjfGZwGP1NbknBMtWUB1XiO7lNIFaqD8Y9QQaLguuC/c5auycpIBhd2o27QlkWsHWB9DjU0EGv44szAeLD05zfJ8DmhTDF4oDtfP2YP6e7jOhHBueZru5Z4ZN3TGz5BkMrBSrJWY1v4l/uL1RJ/+LEV8dygwnwQXiuY1hT2Bt9tWqxhPuUpNW91XRAm6PuU4zJOaAzY73veglWi2NWssLGBN03+1iIJWw9Rt/8nBnMSuxGkiv30lV3tsK/BjA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 27 Aug 2020 16:14:56 -0000 Received: by ary.qy (Postfix, from userid 501) id 178571F34A50; Thu, 27 Aug 2020 12:14:56 -0400 (EDT) Date: 27 Aug 2020 12:14:56 -0400 Message-Id: <20200827161456.178571F34A50@ary.qy> From: "John Levine" To: gendispatch@ietf.org Cc: lists@digitaldissidents.org In-Reply-To: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 16:15:01 -0000 In article <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> you write: >However, both drafts don't provide any citations or quantification to back up their own assertions and recommendations. I think it would be >very useful for a constructive discussion if the draft authors could perhaps provide a bit more grounding to their arguments. In my experience, appeals to external authority in the IETF are deeply counterproductive. I have also found that it is a poor idea to assume that none of the people in the IETF are involved in or familiar with other software and standards organizations and their processes. R's, John From nobody Thu Aug 27 09:34:13 2020 Return-Path: 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 79CBF3A10C0 for ; Thu, 27 Aug 2020 09:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, RCVD_IN_DNSWL_NONE=-0.0001, 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 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 LsXVeEOSUGbn for ; Thu, 27 Aug 2020 09:34:09 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F1C3A10E1 for ; Thu, 27 Aug 2020 09:34:06 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1kBKqM-0005cH-RP; Thu, 27 Aug 2020 18:34:02 +0200 To: John Levine , gendispatch@ietf.org References: <20200827161456.178571F34A50@ary.qy> From: Niels ten Oever Autocrypt: addr=lists@digitaldissidents.org; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtC1OaWVscyB0ZW4g T2V2ZXIgPGxpc3RzQGRpZ2l0YWxkaXNzaWRlbnRzLm9yZz6JAj8EEwEIACkFAlgvB3YCGyMF CQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRAO2D86RorIs56yD/44BSJvKnjH ex0nhPDI9nIJlzlnypa4qsniy0obG5GRbVRikT1E1xaz7VBoPs39hCywoIWd6p0hs1PG1Tcj WV0GwNKRt90PPEh6iNJSGjV2Aq3IlME/aUViD9008yfbRSqfsnPXLW1kpCoZNaOSNzpURoM9 OkVU/z4LSLD61SfFFByBne/GkJKt96/fcspBif1GPC//63ZKFrDqQ9JFR6dECAmsKv7baayz MTv3wrTcqpuHcqJIv4vTm8IPx1QiGgEvrMwsPZz/vx8bMdxxxHWgCcbrt+0b3tRzq9ATZwG3 xDiwnJgKd+ioZOC/b5sY69721sqwBmWYyXWVqtqt01xIgNZjr/wixam+l1bTGUgj0rwPWJWx +7Whe25ff+mNNW/UQeCBjZlxoxAJWSr1Pp3n+SQKQ4TLs8wIwHZtcVCffepfHd47CEbnR8Kc Tjm3tlKzSWq4zcUy6BaxHfgn9+HaAM7fwLqx9/WAtSfdmLXJTN+Swy0w/slakD75jl2o7U3e ETjoYQWt+306X2Uly/0ge7VEQ4ySmmbru6U5ainGE95gjsc++s+hvKmMuGYL3h4ijE1RSe/k wgM6/Z1B6JosssdX+KRuuk2A4FHGbcee8LUIJ3C36qyI7s6PJBXi6SjIPN0wpx30P/DUf/Lr o5lmHF03qQ5eeqI8lDwIobWlJbkCDQRYKXEdARAAxYOE3/AFmEfQ0SVVFujYFhZKX+BGXolY ytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fxj+uXvLKAm9xQRI/DCug7/NGULMk9 bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHwyIawsSCN9AhDXZQWVRqkR1QXcq3I YKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVOBR8xUCBbyk5aRW4VSGO6pUD3H21u r+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8ITaNdFSAttkdT56wAQpxE2h8zaOmBa FUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZtPP9gIX+ic8QO5iuct37bRXJU/rm rH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJHE8JMaX0yYT6h4PGRS3mNM4bka8hj dfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCVaTfJLFPEru3drxNwi6ogdkRmcLGK qqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+uPlDtuExehLsNOMpjP8qhZpFtyLe DS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwODyVwk3MK5Em4pJ0+IAJx+F6gta0B k2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAKCRAO2D86RorIs0ykD/4t151SZG9M beKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvbgB4CtkBuXQlq+plOBWv+rFEThOzy 3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK83OGnfM02qP1Ky8d7EoZz+nTSMf/ DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9Oy1wWy6fHjwx3r+wQSokBNfxgQyAF onmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDvLwOUYKevBIeJJcqTyfAn3TtJbPCE HOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWvKKmBNBB5OJ/rmHogbNU+wWPJ723q MBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiGpWv4tMc5oB/qVh3my1VO65ErcJ3S 9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJBX6jeYZabGvnTicQlBAzfGpblFqV 3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0OhbnytnopKJKk99bwMoCqDkfQvT3 LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ9DYmtE40zO6g70VVxUj+dKt2hbJT y/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <06ef9a0f-ffe4-4b29-e45b-9674488d8d1c@digitaldissidents.org> Date: Thu, 27 Aug 2020 18:33:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <20200827161456.178571F34A50@ary.qy> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: 29cc722430e8f1f6ed904119444c0d49b0f3ee91 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 0ccaee305be983877c9e38c09cbf8ec4 Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 16:34:12 -0000 On 8/27/20 6:14 PM, John Levine wrote: > In article <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> you write: >> However, both drafts don't provide any citations or quantification to back up their own assertions and recommendations. I think it would be >> very useful for a constructive discussion if the draft authors could perhaps provide a bit more grounding to their arguments. > > In my experience, appeals to external authority in the IETF are deeply > counterproductive. I have also found that it is a poor idea to assume > that none of the people in the IETF are involved in or familiar with > other software and standards organizations and their processes. > I actually _do_ assume that people are involved with other software and standards organizations, or that we could learn lessons from them. Else we would suffer from extreme 'not invented here'. We wouldn't want to say that any knowledge or experience outside of the IETF should not be deemed valid inside the IETF now, do we ? Especially not even if these are people who studied this topic extensively or have implemented exactly what is proposed here? Best, Niels -- Niels ten Oever Researcher and PhD Candidate - DATACTIVE Research Group - University of Amsterdam Postdoctoral Scholar (abd) - Communications Department - Texas A&M University Research Fellow - Centre for Internet and Human Rights - European University Viadrina Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas W: https://nielstenoever.net E: mail@nielstenoever.net T: @nielstenoever P/S/WA: +31629051853 PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Thu Aug 27 09:34:59 2020 Return-Path: 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 35B783A10AE for ; Thu, 27 Aug 2020 09:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.846 X-Spam-Level: X-Spam-Status: No, score=-2.846 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, 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 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 C79pBAoeWEkn for ; Thu, 27 Aug 2020 09:34:56 -0700 (PDT) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF1393A1094 for ; Thu, 27 Aug 2020 09:34:55 -0700 (PDT) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1kBKrW-0005r3-1t for gendispatch@ietf.org; Thu, 27 Aug 2020 18:34:54 +0200 To: gendispatch@ietf.org References: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> <8BD7761E-0DD0-4B1B-88FD-51FD5DAE3683@cable.comcast.com> <6572756a-4679-79b6-8f40-ebc2b748b2d4@network-heretics.com> From: Niels ten Oever Autocrypt: addr=lists@digitaldissidents.org; prefer-encrypt=mutual; keydata= mQINBFgpcR0BEACnfvNwTMlN+pyZT0AFYhWqxG3N4AoPIeNfbxLQH7dk8ZL7Ls05xtORfnu9 ovoaRrZpDufkMviUFidNYePbQNdgf63vWVgwpQR7utluwWraetcmZOu6tayJuyBK2b6d2Z23 MJAQxfa2/GMlN3QkvobaoyKtgbc8rOCgNla7WwkgtiVJ89xbAUHXPFpKWZluVRjaFh4p5C5r 7E5OvUiEGLQ5Cn2ir2PGIyIVqjB+hLTyaI6dIGCz2jtL0RATjmsmYUX7UkU/pz8MPPC2BJ5P KU9pdXMRBhAStxcph8vCo2ze9xSi3+1/5A2ULVtvO4s0hZ+exbTfMxMg3H5CCRFEEJXlQEXa Cd0ZHvqcv5xq8n9w/Ccd0CqYWATIwyP8Jlzd+BY3QGTWnWlgoAbs3Guh/pFYhEFNuuAF5Jk1 k5OlNGsRE/LQJmbT5SE7AtLJLbWewcHlEyIH+K6J8uVa4ExLXmRy+eRkFaxjGy3fLlUpy1Ee 1kU7VsQ/TZ8g8ujsMzxqsdB6y0TD/kVlWaDqPL6F+b+pm3lAuCBGWM1YZROTG58R6pD7sNVm i0ift4dIttAsg+2KoShm9A8kQ3tACXZDgNPC0l7VOqnVayjnF0RmjGeiX7PjOcLQCZ9a5wAH 5mrXMaKvfszqAVkP9HSrk1QVZOipF6vEimL43Czy7Rp1aUaUwwARAQABtC1OaWVscyB0ZW4g T2V2ZXIgPGxpc3RzQGRpZ2l0YWxkaXNzaWRlbnRzLm9yZz6JAj8EEwEIACkFAlgvB3YCGyMF CQlmAYAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRAO2D86RorIs56yD/44BSJvKnjH ex0nhPDI9nIJlzlnypa4qsniy0obG5GRbVRikT1E1xaz7VBoPs39hCywoIWd6p0hs1PG1Tcj WV0GwNKRt90PPEh6iNJSGjV2Aq3IlME/aUViD9008yfbRSqfsnPXLW1kpCoZNaOSNzpURoM9 OkVU/z4LSLD61SfFFByBne/GkJKt96/fcspBif1GPC//63ZKFrDqQ9JFR6dECAmsKv7baayz MTv3wrTcqpuHcqJIv4vTm8IPx1QiGgEvrMwsPZz/vx8bMdxxxHWgCcbrt+0b3tRzq9ATZwG3 xDiwnJgKd+ioZOC/b5sY69721sqwBmWYyXWVqtqt01xIgNZjr/wixam+l1bTGUgj0rwPWJWx +7Whe25ff+mNNW/UQeCBjZlxoxAJWSr1Pp3n+SQKQ4TLs8wIwHZtcVCffepfHd47CEbnR8Kc Tjm3tlKzSWq4zcUy6BaxHfgn9+HaAM7fwLqx9/WAtSfdmLXJTN+Swy0w/slakD75jl2o7U3e ETjoYQWt+306X2Uly/0ge7VEQ4ySmmbru6U5ainGE95gjsc++s+hvKmMuGYL3h4ijE1RSe/k wgM6/Z1B6JosssdX+KRuuk2A4FHGbcee8LUIJ3C36qyI7s6PJBXi6SjIPN0wpx30P/DUf/Lr o5lmHF03qQ5eeqI8lDwIobWlJbkCDQRYKXEdARAAxYOE3/AFmEfQ0SVVFujYFhZKX+BGXolY ytC2a1soZogVYTIIlypxkRtN+ljteFAY3xX/El7cx5Fxj+uXvLKAm9xQRI/DCug7/NGULMk9 bDK5bzSGw817cyiL5Kb+0RkWj2Y5ArOAK6XPGBZWZTHwyIawsSCN9AhDXZQWVRqkR1QXcq3I YKl+OHWMO7+1VfixCSakNf7T/Kiq46rQEPW8Eghk6CVOBR8xUCBbyk5aRW4VSGO6pUD3H21u r+5fTLsVyan1NHhxNNiXfnEJKr+JI5dXSkj7WqA5n8ITaNdFSAttkdT56wAQpxE2h8zaOmBa FUWQ4D8SdXDVymP5QMtLG+ItMMiNV6kXgsRFugAKM5yZtPP9gIX+ic8QO5iuct37bRXJU/rm rH54Ab0kyAeeRE7oSsfTZPKvgtUh7VLAUEw/wy6TORJHE8JMaX0yYT6h4PGRS3mNM4bka8hj dfcrexI0zSqFOl2I22zQlG3YqSzIvVh98W67hxfAIaCVaTfJLFPEru3drxNwi6ogdkRmcLGK qqTgeYItrvITyFvzqbrcO2exp0KKEK3cDIZypqHHUf4+uPlDtuExehLsNOMpjP8qhZpFtyLe DS07qunbvstcyvR30wOJ3DyAbHGzq739UyDcO9Jt5jwODyVwk3MK5Em4pJ0+IAJx+F6gta0B k2MAEQEAAYkCJQQYAQgADwUCWClxHQIbDAUJCWYBgAAKCRAO2D86RorIs0ykD/4t151SZG9M beKRVKbs9Ecjady9bO0L3oBos4rhqY12ha8smFlsUzvbgB4CtkBuXQlq+plOBWv+rFEThOzy 3bezgEDjlxycoO1W2wJD6E7Fo9fkHT6UOm9fQBkuKRqK83OGnfM02qP1Ky8d7EoZz+nTSMf/ DJgWw1YRKrXkMHBwKD83lCENsmePWE5AjMqk8cojPv9Oy1wWy6fHjwx3r+wQSokBNfxgQyAF onmgBbhlic/pZUYRSIcldyUlaomrjFfr4egzmNE7aWDvLwOUYKevBIeJJcqTyfAn3TtJbPCE HOC2+lP6EcmPFyhQdiia+RqOClumqbWOPeQ2VM8j7NWvKKmBNBB5OJ/rmHogbNU+wWPJ723q MBoOp1jIwFNkQhx01W6v55VMwLr+IuBKY1ggJ2BhwQiGpWv4tMc5oB/qVh3my1VO65ErcJ3S 9blpwJdDj5/YDOU7BKEmpRUP+xkaryNzH2x7FzrOOHzJBX6jeYZabGvnTicQlBAzfGpblFqV 3YN6EhCF2AHmGLTZ/DrjGYToIsW8cXlEMqN4u8ODEUY0OhbnytnopKJKk99bwMoCqDkfQvT3 LKDWtZj9NzFndfuoKXsVpwAitrG0mau0/16DKDyVWdtJ9DYmtE40zO6g70VVxUj+dKt2hbJT y/KQTb7Ijhw7wZrGp/P7nhbVyA== Message-ID: <3c52a08f-db79-765b-310e-6231b04df1a6@digitaldissidents.org> Date: Thu, 27 Aug 2020 18:34:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <6572756a-4679-79b6-8f40-ebc2b748b2d4@network-heretics.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Authenticated-As-Hash: 29cc722430e8f1f6ed904119444c0d49b0f3ee91 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Scan-Signature: 5a1627636b35b65657045ef62631cd80 Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 16:34:58 -0000 On 8/27/20 5:13 PM, Keith Moore wrote: > On 8/27/20 10:56 AM, Livingood, Jason wrote: > >>>     More broadly, the burden of proof should be on those demanding potentially disruptive changes >>      [JL] I'm not sure how a change from the terminology of master-slave to primary-secondary can be considered disruptive - it seems a little silly to suggest so. > > Without going into detail, I don't think I have as much confidence as you do about that. > > But to clarify, the potential disruption I anticipate and want to avoid would probably be due to any of: > > (a) interminable or repeated arguments about whether it's ok to ban or even discourage particular terms (like "master") for which there's little etomologic justification and a large potential loss in terms of readability if the term were banned; > (b) the possibility of documents being arbitrarily blocked by IESG over the documents' use of certain words, without the backing of community consensus; or > (c) documents held up interminably (in a WG or anywhere else) over disputes about terminology. > My question would be: what is this anticipation concretely based on? This this actually happen? Best, Niels -- Niels ten Oever Researcher and PhD Candidate - DATACTIVE Research Group - University of Amsterdam Postdoctoral Scholar (abd) - Communications Department - Texas A&M University Research Fellow - Centre for Internet and Human Rights - European University Viadrina Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas W: https://nielstenoever.net E: mail@nielstenoever.net T: @nielstenoever P/S/WA: +31629051853 PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 From nobody Thu Aug 27 09:47:49 2020 Return-Path: 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 857103A0911 for ; Thu, 27 Aug 2020 09:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 nszsz_UmVzXf for ; Thu, 27 Aug 2020 09:47:47 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9249F3A08D7 for ; Thu, 27 Aug 2020 09:47:47 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id C5A285C0053 for ; Thu, 27 Aug 2020 12:47:46 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 27 Aug 2020 12:47:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=gi17dIstL1Ha2ksnCMNWMRKV7eqtaWEqydNmn6jkn ck=; b=ScWrIQ7iuQTprtp7uwXe4RVbw8CKiqDVLgh0FMlHxmVHr5sEUx1O9tIhV dC1FsqXUOdXQBJ2HOqkQ8AwDZ3JqY5yuaGRyvxqgVKDFtCLcuofOHq6CU+lfUrIM vSm/P9NJgLVo0zl+St8FlwgVP6VACE6Mf8YRK/dq4AkqJojquHpJ9p59lUf/BdZU Xjd21lN2PB7dHN4DWrI3Rd+xnOpVBoS2riG62YxWQcswgVjGpfdbi/Jdi8k37VBG MMBcLDr5roctt9DyzUo+Epd/WOaH+RrbY3Jk5I1TLJk97mZv9s9Ckxbv01N6GxWh 57O0gIP5R+745ANv1F7Xy+ZBr05bw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvgedguddtudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesth ejredttdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvght fihorhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhepkedvgefgle euleekuefhffehgefhhfekuedvudduiefhhedufefftdfgtdekfffgnecukfhppedutdek rddvvddurddukedtrdduheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id DBF0B3060067 for ; Thu, 27 Aug 2020 12:47:44 -0400 (EDT) To: gendispatch@ietf.org References: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> <8BD7761E-0DD0-4B1B-88FD-51FD5DAE3683@cable.comcast.com> <6572756a-4679-79b6-8f40-ebc2b748b2d4@network-heretics.com> <3c52a08f-db79-765b-310e-6231b04df1a6@digitaldissidents.org> From: Keith Moore Message-ID: Date: Thu, 27 Aug 2020 12:47:44 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <3c52a08f-db79-765b-310e-6231b04df1a6@digitaldissidents.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 16:47:49 -0000 On 8/27/20 12:34 PM, Niels ten Oever wrote: > My question would be: what is this anticipation concretely based on? This this actually happen? Yes. From nobody Thu Aug 27 10:21:40 2020 Return-Path: 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 763E63A10D7 for ; Thu, 27 Aug 2020 10:21:38 -0700 (PDT) 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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=comcast.com header.b=bFX9KKxA; dkim=pass (2048-bit key) header.d=comcast.com header.b=S5x47pZz; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=TaVS3BVZ 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 E4_ItPbVaTe0 for ; Thu, 27 Aug 2020 10:21:36 -0700 (PDT) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FDA13A0FCF for ; Thu, 27 Aug 2020 10:21:36 -0700 (PDT) Received: from pps.filterd (m0156894.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07RHIdxr020258 for ; Thu, 27 Aug 2020 13:21:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=b4rP1Ly6C0y24Wt4hvODxtcy6s829btloGbhTDgsr78=; b=bFX9KKxAUpeepB2wm06jlbvAPB3Pfb39W12+U1T8Pc/JqTtdbm5i4oCDGixRDd/P3A5e Y41WaPrZenqnT57ukSvvaKLcNzlv/+OYC6ZmT1Xj6PqflnV2HTeO3zbyzP1GvDz3FdPW dco4izACT0RdpuSudT+LuQoCZBROtlif/awiHohaczOS2LJJAM6zDwnbVkRYp6Jy9Xot TTwxfsEXdT7Za0ruN1EkMkjUE1oDO7lpujTkyxBs/WAVIhR3XFXakxMq5ZSUbygSWy8E wAJfWEYK9U3IXjHgjXoD1LATCynD0BwHHczeiNfZbCC4F1mrOVfOCIZWeikyI78b+b2h Fw== Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0b-00143702.pphosted.com with ESMTP id 3354mb5720-59 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 27 Aug 2020 13:21:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1598548893; x=2462462493; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=b4rP1Ly6C0y24Wt4hvODxtcy6s829btloGbhTDgsr78=; b=S5x47pZz3UY7AJYjiyRuRu0sy1u4Yg8Y76+bl83ujpZ6Ej5Oz7fWbpStBoRxFeDN r+8Xm+arL+o7EjQQCDa1nWIoJuzAUp/SGpt9KkNy0fI/Ak680Z73GGPfZ2r5cnQJ XR70jo79+BWacObUb6gL+9tBHcKWxsuVHyimEsOBCx2PuG91qCqI1htoVcyQ5+al Kmxkg3OuXtuX6g4HLFJD30tIqH22/O8U7zzSW/o2G5A8gwMp+eSfuRlnK55NJwqf mlOoSk2ruJIKR7cq2ywsd4L66sSoWKo5FLme16vt93v52mFWNb9f3K5ERHqBd//H mWlgvosFQgO9mbZmt4TxkA==; X-AuditID: 60729ed4-a49ff70000003048-1d-5f47eb9d2b32 Received: from copdcexc34.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 04.35.12360.D9BE74F5; Thu, 27 Aug 2020 11:21:33 -0600 (MDT) Received: from COPDCEX13.cable.comcast.com (147.191.124.144) by copdcexc34.cable.comcast.com (147.191.125.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 27 Aug 2020 11:21:32 -0600 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX13.cable.comcast.com (147.191.124.144) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 27 Aug 2020 11:21:32 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.168) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Aug 2020 13:21:09 -0400 Received: from MN2PR11MB4287.namprd11.prod.outlook.com (2603:10b6:208:189::17) by MN2PR11MB4256.namprd11.prod.outlook.com (2603:10b6:208:17b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Thu, 27 Aug 2020 17:21:07 +0000 Received: from MN2PR11MB4287.namprd11.prod.outlook.com ([fe80::b951:e489:324b:cb3f]) by MN2PR11MB4287.namprd11.prod.outlook.com ([fe80::b951:e489:324b:cb3f%6]) with mapi id 15.20.3305.032; Thu, 27 Aug 2020 17:21:07 +0000 From: "Livingood, Jason" To: Keith Moore , "gendispatch@ietf.org" Thread-Topic: [Gendispatch] Grounding the exclusionary language discussion Thread-Index: AQHWfE+1h05Ww0QqwEekroA7vDf6YKlLqyWAgAAdmYCAAEfOgP//4KyA Date: Thu, 27 Aug 2020 17:21:07 +0000 Message-ID: <6AEF509D-A5AE-4AB4-80F5-9B99EDEA66C3@cable.comcast.com> References: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> <8BD7761E-0DD0-4B1B-88FD-51FD5DAE3683@cable.comcast.com> <6572756a-4679-79b6-8f40-ebc2b748b2d4@network-heretics.com> In-Reply-To: <6572756a-4679-79b6-8f40-ebc2b748b2d4@network-heretics.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: network-heretics.com; dkim=none (message not signed) header.d=none;network-heretics.com; dmarc=none action=none header.from=cable.comcast.com; x-originating-ip: [2601:87:4280:7190:34a9:157:896e:48fa] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 06c9fc41-e2be-48bd-e536-08d84aad9601 x-ms-traffictypediagnostic: MN2PR11MB4256: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1360; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: h/dBEbn6FpCXjpk4lKNdBLOU/iLTWN9E0swI56RNJfJJYunOsjJm5XL1VwjH1IfKTygRJUWe9Q4860yfFraG5wRRaGQ39EvTEltEQao19/bQy9uQhPEeTAS1tKHyAzAEzY8LOjhmTj82Ws74bBt3FlhhH4Zii6HXB4Mo29+erF3F6sox1NybDfmTqmnr8tPQU+rj9LAAkJNTsUkjc1LlK87zAIVOr40cK0b7MD1cBBKr/dNPeQ/KH7DOLZh6yOrPlbvA7U6x9V4VdcCq2bZv6w6v9PEhmIqeoDFBkHOHifA1gWaB/FM6bTqoeBVl2kC+f3RnLBU17sgxzFid/XVK/Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4287.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(396003)(346002)(39860400002)(366004)(83380400001)(66476007)(64756008)(66556008)(6486002)(66946007)(5660300002)(71200400001)(110136005)(66446008)(33656002)(316002)(8676002)(76116006)(86362001)(2906002)(6506007)(186003)(2616005)(478600001)(6512007)(8936002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: MDNUgAx0qGJ1aUWsyu6C2HxV/Enk9mr8qHCRwYcXi2fapiyHOt1ZGvzRlsFgh3H1W+MO+abMIlXlRHVc2q9bg8Z6MKUyxauSx+35lMTGdwtRRIzSEOJHJignaNT/Rsi1pk6nfm1tkRuNnoncQbVwGO1FltgHXL+R6Ai4MHVpRJyQ+ePxEC2tbkTR8X1kjMa+tKeJ5cUq/sgisb6Xtc4w0L52C3iRzkr5PsaRH7xlqn9okO2lB77w8DgzoajGqLUfB7gYqNm7gxw1w1F0m/TbcXf4NIlhkqeVxuBbzusaKrCr+RmCVnF8HS4Zm538Xdd+kxEDqL7uIgfqddwwLvchRHpa3QUYUqbuL2v+GecK7Q7wFMa2dRYqtkbtUcIfwRKd77BynsYLfhodmte0SoRCxcUfpecpWFSzQuRHsA358LHDMAGsJiACx8hSWSdHIg1EWAF6Ml+mEcnSQLVD/pMr4ju3BRzDj1vjhYlvVhELQUjnj0flmlsQz/B1mMTpFhmHaLh7BZuaE8UCZ1IO65zsQs9LCA3yQzZr1sww3Z17wCLCB70wmORkU48mKVYL2Ioa+Zelwr5f0cPxnD9qkvcjb9zwRE3sVUjr3JjbBqY62EQULiRQA5Pk9TosMUbV9MshqWTUU2285Wnx0GCYRkNswcL1cxTkgm39FDYc1lF5rSW1u++YEoxj5rOZ1D5/DiNZlQJbR2EY+miwSGs+1KjDlg== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J2oeXbZTOsspLgtzZEjU6uZWXshvTkqfdZxnktXcUx9SHcXqs1IUkzOwPhHrq6aKgnBr1X+bLl/zJeKapvJjIMX+9WAUnDLYT4vmT+mYft1sh0bj4p7ymnw4AJnjRZDu4Xv1zrK5Jv2rEgZPQzsuix32BRnpwVBshW/H4QzZUmbY6pwPfCQN1Kp8GsZQ9V5x6JhvUO5N3ZnLRdMcjU8KB7uXen7f8OWsmHPFFeKwpxbsVQRX6ce5P0q5QuH6hb5yfI43aO8Jfnj9HlTgJ5mExUB3rYJPI8AiLHi9QMaHkRkWay8ohx51ojis7Ii8fd+9zYK8KXHIz5kEeR04zgA3EA== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8IIbd6IaTxAnSvq1PpKl5rNaRG7rogCqjjTtxiSPjv8=; b=SvNaxvoE9mZWqfHvelDuq4Un5ngyfIXOQOFNmwC5XfcaXfO7Qql4aoDtKArGRiLBljisWo2pY8sDPfg290tUnReuiE4y7pwEwI9qdXQaYR5dXZsjmhsZ6jRUEhukOLMazLM99CDY1bEHxwZ95a/x8qFJkHOMcXg62BtuQ5DF3DDGevmEW0mo5KYFfdrjAqWmRvyORROCa8hAsUI1jEHkFcc9h4Az1MQQKOXiHArF1eWvLZfw/MCj3MmE996DDlAbsxrK07LcAxk8eiKPuemjNZ+/we4F8IHR+iMZF3OwMDkVcrTresbJLO49I8dRQL+K4IMj5lwy1KwlRBwuTHnsqA== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8IIbd6IaTxAnSvq1PpKl5rNaRG7rogCqjjTtxiSPjv8=; b=TaVS3BVZFeKgI3o66mDAGMe6Z0hlgx6aa5YbeVEeB6GkPXlKRIsztKmpx0tpACVgUd2QWNr1e+2up4R5PZVVRP8fhYQvEcJ/rBwOJ+9LGHfLwNyVe2TcrP2/zZm3KZkip0RU91ppD5SPK7SPOVjCllpdmXOV4TU0JuSihmICtUE= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4287.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 06c9fc41-e2be-48bd-e536-08d84aad9601 x-ms-exchange-crosstenant-originalarrivaltime: 27 Aug 2020 17:21:07.8430 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: c9iMRPPxcfU7Rct0U6pypEhPq5LvsqfGnaqzdnHNRJhZaTNv1N2COIg73HAaQvIsCCDmRmcd3b7+wHbBukWUMYL4dx6ZgI1vzcemc7RxIws= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4256 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <9AC34476BE73F948BA00E8B7B8E2344C@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHee69m3fDxdPUPGkWzbQS3JqoLYiUjJyF1BcFFdOBFxVf2VQ0 FEamxszSlYiSb21CykAw3/IFYr7QIrWmQUUDX7M185NzhaTt7hr07Xf+58855//w0KS4lhdA 5xaWMOpCVb6EL6Qy1c+ehLc74jMutDh8FJ3aFzyF3jnPjyWURuNvQql/k3ybSBVezmLyc8sY texKpjCn0XUPFZtE5ZMzSi3SinRIQAOOhIFdE9IhIS3G0wQYJ5u9uKKagJqNcYp1ifFXBIub RVzDgqDn8TzJFT0EbK9OkJxrFcGPiVMs83E02LqXPLovToe9ObsXyz44AXR/bIQO0W79Bjg3 4ji8DtamGNZB4RB4/q6Xx7IIX4PB7mGKW3WAwLo86DlIgJWgN7xELCN8DFxvTQTLJPaHL+ud BBcNg3FigeTYD+xr+56hflgGjgevCHYown3uYK3f+ZxJAWObw14cB4G1sx5xnAi2GtehJwx2 bXUUx3nwfm6UYgMADoUGQyEnn4S+hpVDywlY/jTCZ3cB3iPg44aT4AozCT93GqhGFNX23+Ft 7lkkPg/9YzJOVsLS1EPE8Wl4Wr/i1eZ5mKNgaV2nuhCvDx25FC2VyyOl8iiFNEIeMYA8v6Nj aRQttijNCNNI4i3SfYvPEPNUZZqKAjMCmpT4ihwzbkmUpaq4y6iLMtSl+YzGjAJpSuIvSk+f uyPG2aoSJo9hihn1vy5BCwK0aMgvKTR4arnDsOA8flU6lXezGdXNBzUWz1pbzyWOhiTNxlm3 prddyU2x1c2Wdpv3xf7W2jDT3uvV8FKiaFEQmFz1KLV9IMXexTgMO7Km+xO/sqZdO0PZBfvh 41XBlRaHPYFM2/rQe2uksvzs50WflbG5tDMqzVpLzIFdmhKrl1CaHJU8jFRrVH8BMK4RUxkD AAA= X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-27_09:2020-08-27, 2020-08-27 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 17:21:39 -0000 KHBlcnNvbmFsIHZpZXdzIC0gbm8gaGF0cyAtIHNlZSBpbmxpbmUpDQoNCu+7v09uIDgvMjcvMjAs IDExOjE0IEFNLCAiR2VuZGlzcGF0Y2ggb24gYmVoYWxmIG9mIEtlaXRoIE1vb3JlIiA8Z2VuZGlz cGF0Y2gtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbW9vcmVAbmV0d29yay1oZXJldGlj cy5jb20+IHdyb3RlOg0KDQo+IEJ1dCB0byBjbGFyaWZ5LCB0aGUgcG90ZW50aWFsIGRpc3J1cHRp b24gSSBhbnRpY2lwYXRlIGFuZCB3YW50IHRvIGF2b2lkIHdvdWxkIHByb2JhYmx5IGJlIGR1ZSB0 byBhbnkgb2Y6DQo+ICAgKGEpIGludGVybWluYWJsZSBvciByZXBlYXRlZCBhcmd1bWVudHMgYWJv dXQgd2hldGhlciBpdCdzIG9rIHRvIGJhbiBvciBldmVuIGRpc2NvdXJhZ2UgcGFydGljdWxhciB0 ZXJtcyAobGlrZSAibWFzdGVyIikgZm9yIHdoaWNoIHRoZXJlJ3MgbGl0dGxlIGV0b21vbG9naWMg anVzdGlmaWNhdGlvbiBhbmQgYSBsYXJnZSBwb3RlbnRpYWwgbG9zcyBpbiB0ZXJtcyBvZiByZWFk YWJpbGl0eSBpZiB0aGUgdGVybSB3ZXJlIGJhbm5lZDsNCg0KW0pMXSBUaGlzIHNlZW1zIGRpdmVy c2lvbmFyeSAtIHRoZSBkaXNjdXNzaW9uIGhhcyBmb2N1c2VkIG9uIHJlcGxhY2luZyBtYXN0ZXIt c2xhdmUgd2l0aCBzb21ldGhpbmcgbGlrZSBwcmltYXJ5LXNlY29uZGFyeS4gVGhlcmUgYXJlIHNp bXBsZSB0ZXJtcyBmb3Igd2hpY2ggSSBzdXNwZWN0IHJvdWdoIGNvbnNlbnN1cyBleGlzdHMuIEFy ZSB5b3UgYXJndWluZyB0aGF0IHlvdSBmYXZvciByZXRhaW5pbmcgbWFzdGVyLXNsYXZlPw0KDQog PiAoYikgdGhlIHBvc3NpYmlsaXR5IG9mIGRvY3VtZW50cyBiZWluZyBhcmJpdHJhcmlseSBibG9j a2VkIGJ5IElFU0cgb3ZlciB0aGUgZG9jdW1lbnRzJyB1c2Ugb2YgY2VydGFpbiB3b3Jkcywgd2l0 aG91dCB0aGUgYmFja2luZyBvZiBjb21tdW5pdHkgY29uc2Vuc3VzOyBvcg0KPiAoYykgZG9jdW1l bnRzIGhlbGQgdXAgaW50ZXJtaW5hYmx5IChpbiBhIFdHIG9yIGFueXdoZXJlIGVsc2UpIG92ZXIg ZGlzcHV0ZXMgYWJvdXQgdGVybWlub2xvZ3kuDQoNCltKTF0gVGhvc2UgYm90aCBzZWVtIGxpa2Ug YSBzdHJldGNoIGJ1dCBpbiBhbnkgY2FzZSB0aGUgSUVURiBoYXMgd2VsbC13b3JuIHByb2Nlc3Nl cyB0byBzb3J0IG91dCBwdWJsaXNoaW5nIGRvY3VtZW50cy4gSSBkb24ndCB0aGluayB5b3UgaGF2 ZSBtYWRlIHRoZSBjYXNlIGZvciBzaWduaWZpY2FudCBkaXNydXB0aW9uLg0KDQoNCg== From nobody Thu Aug 27 10:22:05 2020 Return-Path: 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 9B8FE3A10DA for ; Thu, 27 Aug 2020 10:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=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=comcast.com header.b=5tOgnhYB; dkim=pass (2048-bit key) header.d=comcast.com header.b=FNTj497P; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=nemsajvn 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 A1y5i5yuD9lv for ; Thu, 27 Aug 2020 10:22:01 -0700 (PDT) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374EB3A10D7 for ; Thu, 27 Aug 2020 10:22:01 -0700 (PDT) Received: from pps.filterd (m0156892.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07RHKKsb006005 for ; Thu, 27 Aug 2020 13:22:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=Od7aJ2vr93LQgZ4oHysLeDDAVpgFjpwRJ08Q34bWAf8=; b=5tOgnhYBMvG9dZhkxgMQ/YImIRQ9gsX3F/O3tVxnwndLkyiFZvtkN40O/T9rqrk46Hvc h0phyksAXCLphZYJwJOG2sTTvHBdt2oWDzXK8RPp+58gX/AJFwT4FagIGSsaPj3+5Xwi dzASwb8klLIXFSH4+8vfRWwnbqaQKTyB9eaDz0MiW2YIRLgcS4hQPPIa4B+ri+NaszjX kE2SOyfbLq433NK+MYMYbEU8CVMpLa1Z9ym2qLfcyWrNO0ESaZDFNDQT/FHnXV6Ggx56 EsEWJ6P4/XFpx2sGrSmsAkU1GmQV9NFptsgW/MPZQ+5HAV/cnE3ZUKQv/c8g7uDnt4Fe cA== Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0a-00143702.pphosted.com with ESMTP id 332xphmeb6-33 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 27 Aug 2020 13:22:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1598548920; x=2462462520; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Od7aJ2vr93LQgZ4oHysLeDDAVpgFjpwRJ08Q34bWAf8=; b=FNTj497P8I5NNvWl/fTl7xgryItQFrl1a6pw2l26/AeEq9yKTZgSi/0a/4A4np39 1bWafOasoyDS9xs8VtEO0mkMtcwMsvsScWyjBslUeUZnp1bKOOk+Aj8fH4CMB6K+ iI2k53Vt81jjybfjqaqXShPx1V3l1xKy2i862S8wjU203altHtkvYaLNLGQbzF40 le2APTTOktwgGnQ/X4d0c/44CIvriTOn7aMEnQ9bAuX9oogs8V5j+a1FJq0gi1nH 0gENdlUp5D5it2UjVFyi3IQxBOOUNmHG/yS1X+ZGzOKUO5JY3v0xRFmtWXH8CwFu V1iiQpym3LYycLdwOONuoA==; X-AuditID: 60729ed4-a49ff70000003048-5e-5f47ebb8dc9b Received: from COPDCEXC35.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 5D.35.12360.8BBE74F5; Thu, 27 Aug 2020 11:22:00 -0600 (MDT) Received: from COPDCEX13.cable.comcast.com (147.191.124.144) by COPDCEXC35.cable.comcast.com (147.191.125.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Thu, 27 Aug 2020 11:21:59 -0600 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX13.cable.comcast.com (147.191.124.144) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 27 Aug 2020 11:21:59 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (104.47.55.170) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Aug 2020 13:21:40 -0400 Received: from MN2PR11MB4287.namprd11.prod.outlook.com (2603:10b6:208:189::17) by MN2PR11MB4256.namprd11.prod.outlook.com (2603:10b6:208:17b::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.24; Thu, 27 Aug 2020 17:21:39 +0000 Received: from MN2PR11MB4287.namprd11.prod.outlook.com ([fe80::b951:e489:324b:cb3f]) by MN2PR11MB4287.namprd11.prod.outlook.com ([fe80::b951:e489:324b:cb3f%6]) with mapi id 15.20.3305.032; Thu, 27 Aug 2020 17:21:39 +0000 From: "Livingood, Jason" To: Keith Moore , "gendispatch@ietf.org" Thread-Topic: [Gendispatch] Fwd: New Version Notification for draft-moore-exclusionary-language-00.txt Thread-Index: AQHWfAjdv1OmGe9RyUuqtAR8Elqe/6lL8esA Date: Thu, 27 Aug 2020 17:21:39 +0000 Message-ID: <09E7A82D-EDC6-4DC8-8B9E-4FCB4F4C81A7@cable.comcast.com> References: <159848790676.31401.17151257967664129305@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: network-heretics.com; dkim=none (message not signed) header.d=none;network-heretics.com; dmarc=none action=none header.from=cable.comcast.com; x-originating-ip: [2601:87:4280:7190:34a9:157:896e:48fa] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2a79ae3a-b6f5-4786-711c-08d84aada908 x-ms-traffictypediagnostic: MN2PR11MB4256: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 15siSDivhmqqa4rgG6H8eHrYRQkPp2WAqN9ErfXHcjkqxGguWSpdFFjZpIiKByndkvWnWSxAywHV53IILSwglFpyP/ATB9dVHbA8QPsJyF9ywgHssttLwLWXhTOwl9S3UMjS1UpzUO+Me9hlJPFWqLwIUPvSsVV72Or+rJz9/36l/Uw/xXJvuSLKFqp95vrIIcWSDAcUlnhlqKFqlCPyN+n/1HdcQLv9vMvamOD7Y05Ggv2vw6cKEa44Qe5yj7DsIrKiisCPKf25/Mn7yRzqxq8NK6R1JhcG+FP/B3+KEAepRvIP2rjf0CGUsJyees2VTKIQuia88BmPmXlvtNeFsnTQc5Oqlgt00VKWrArL0cKAgSITcK/mKCGZ02GqXO1tNFEJfNMjcrnEkbB17c0Smg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4287.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(376002)(396003)(346002)(39860400002)(366004)(83380400001)(66476007)(64756008)(66556008)(6486002)(66946007)(5660300002)(71200400001)(110136005)(66446008)(33656002)(316002)(8676002)(966005)(76116006)(86362001)(2906002)(15650500001)(6506007)(186003)(2616005)(478600001)(6512007)(8936002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: WDNYn5YvByXQKGKRmtuoRNl1b9MgnsEZXecaoA3CCo8LYNiS7lYOr4ld8DWTelbs9nlEO5Jk9IrkXPJXQr6Jicbh0tB0AdaQ4lCdyw0O+wIa//Uv2Fw1Lghe4ckCaOYumkoyCZdRamSqKyBeo965FLJ1CG27dPndYyNQDvdBEKPY/FHuhuQXGLEyVzvlFuEsdpqlWrPmfNFzCG5axkV4lywxtjFFuNFqPHDjZjSDjSjrNvth/WUwsO14ChE0FTbzZ4ZxL32ljBLSCKWvVXxsqXv+18bRpES73/ogxxmBG25kIFw9dSvmxlGirk8EO80yvAui1ukmVaje1/htEgQpf0WLMVmOlRg6gNBRARORsy0h7hqC0rTnqpDN6qcTDm0+BeW6tpuljlH4WDIi/S6NObEmrQUAdsIF0owvOOJ9v2r7IvhFzg88QZywFNg+mbLRSSv85eAMJViHLFTnLJ93pTXapIz6Lc82dBRRQihILNE8wjZWFj+9S5Nn6OmbQkXlPWQngqw05L9EoJAYpIBANEBIOVtZlGYqxtBjd6DVlXJ0E/1/1d3fY4CFZwljI0j6dmigZlZA2JmwriQLgkloU638AhWOTCkv8YlhFKF4X5xDC6Ql7+uz/e7PAzcXOb0IgtvYlpIkY66GzoZFKgyAfSmaGvhrdiyuCegi88uvZl4WGrCo0OYGzpQvdY7QmsjfpeSBLLJNMm2vLj0vXgeTqQ== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lnjnanmWWNJ1tRgM4J7hvV+lWGsrHBqEcWzAbLEk3RMuxMZNJEOtHJ4riuZmvmHtbS5LsQixqdBLDOjcNJPTDxZ2lpZIzbd8HfcZr5zEtp5k55yl7fRPtt7thfsbAt9Gac+WWOhB4rvIdfHaCiULreyuAeK/Hx01kQXuzeMN3qfU3hcqTl3oQOZvDoVF8PQc5Z61UqHT1O3BYfkp6Gl27v9h1n+SUjUTUUJpq7l1pJL1jvwQHuKYf1hSYi10XHus6cKblCFxwBJfJdc5pE3gYiuzKDRsVROawnh6fB1ZSUka3ZXYs1DwTpm+7t4IV8DfMm4LEwXYJY/o8VjFCi61Gg== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F54EnVLDP3FlPBE0bk4hbSiijXQL34cpvGqHlKMihpY=; b=nzDGE0fs9klZunbVvaVgVJnA398SL/LOT8489FudTQ6T33Gin+KGm2fXvUweqOtMKN0+f5cRfBMOyInZdIuOw2ptdap9H9M7uhskvQ68T/3mUyyZrmH1uXigcZj4rPfEayobi6hF+CYN3LmBK1tnR2JY5AGwj7BdGiziMpg9NBKSWh1uQE/2RhFJZecStdxgwuA9BZ3xoCCzBOZxMCy4LnTEsGsbJCPEQ+K8Ylo96h0GBA86UAkRcwNseLoDaYfP9NfYuFMDBL1Ze8pIdp9CbxBV/AuH4OgTFq8pdZTvXdrvLBxHYXvKDROz8D8ltzrB2sj8jnJpgP4P+LQ8YXeM5w== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F54EnVLDP3FlPBE0bk4hbSiijXQL34cpvGqHlKMihpY=; b=nemsajvn5cHBqfD4e2SszcogAj9Juph4qvuyoa6Fn4NLAOkohPurRgY4lCt6JYdi22nGau3SoGuHKpU0+CVXX6YXRN2fWiI8oQG8RpwD00kBIMp3f/8VwkjgkqxZrMn0ZTFiW2U05e28Mhio0ERSO6/m5l6biEbpvRim2AupMQA= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4287.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: 2a79ae3a-b6f5-4786-711c-08d84aada908 x-ms-exchange-crosstenant-originalarrivaltime: 27 Aug 2020 17:21:39.7716 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: 37BZw/IFrgcPJ3C8o+aiH3ecAIes0wTYrC/GJP+0h9Zo7ik3SjNIPhAEmkclrhSstJX3pR6F7SdrKKAlctub3FzT7qYzu+h8uxp7vpJseWc= x-ms-exchange-transport-crosstenantheadersstamped: MN2PR11MB4256 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHe+69267DxdPy5agVtOzNUNtQWyThB8NBCfalD8F0Qy9qWyab WdYXs5Uxs0SFcklWTrJVJhPK6SwYWs0wIXWGOsv5NhtCE2aJZW27C/r2+59znnP+5/DQpFDP iaWLS8oYTYlSLeLyKYWmuSGx25OVd/CJKV7aUtnOkdb7PnIzCJnRuEbI6t+fyiFO89MLGHVx OaNJPqrgF7mrb3FLTZKLpho3pxLpxHoURgNOgbtttTw94tNC3E+A689NLiuuEuAwWhArphB0 NKwRrLAj8G20UaxoI6B+bDokXAicy985gc5cnAbOh6NkgCOwHNaHlngB3ooLYWT8N5eNF4HL OhuqkcDEl1oiwBTeDWO+DyjAApwJZvdCaEAVgnmHlwokwrAMLO9agw8QjoIfg8+CTOJomJhr Idj1MBitwyTLkbA0uxE0F4mTwXPDEtwHYROCkSY3ly2SQs/iSx7L2+FTSw1iORu6qlpDTRNg 1VntN0H7WQX6zmI2vAfGVgYolneAqXYmxNvg6+dXwasC7iXh8cIqwYpxEsZ9LqIOpRr+M27w 9yXxfnjRk8yiDOr0arZiJzTWzPAMwbtsAXvTHPUAcUxo8+G0JLE4JUmcKk2SiCVmFPwh90e7 0cgdmQ1hGonCBfqFrDwhR1murThrQ0CTogiBZ8AfEhQoKy4xmnN5mvNqRmtDcTQlihbI5UO5 QlyoLGNUDFPKaP5lCTosthL19e2NWfdtYnhTxw8ds3cNUMuJ3DdX+iejqidPehQxxvTmRR1/ xZHR2P7TOvUt0yyftDuyr6v0g7ZpuzO/M7+/43VcPL5tcTwXXyu8p4pN77XmWnvUB44kmKfD f4ly5r26KN0jD2dfHC0+5OWTQxcunzEMv93V7p0/Ea14WiqitEVKcQKp0Sr/AgHudpQdAwAA X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-27_09:2020-08-27, 2020-08-27 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Gendispatch] Fwd: New Version Notification for draft-moore-exclusionary-language-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 17:22:04 -0000 KHBlcnNvbmFsIHZpZXdzIC0gbm8gaGF0cykNCg0KSGVyZSBhcmUgc29tZSBjb21tZW50cyBvbiB5 b3VyIGRyYWZ0LCBhcyB5b3UgcmVxdWVzdGVkLiBXaGlsZSB0aGVyZSBhcmUgYXNwZWN0cyBvZiB0 aGVzZSBkcmFmdHMgd2l0aCB3aGljaCBJIGRvIG5vdCBhZ3JlZSwgaGF2aW5nIGRpZmZlcmVudCBJ LURzIHRvIGNvbnNpZGVyIGlzIGFuIGltcG9ydGFudCBwYXJ0IG9mIHRoZSBwcm9jZXNzIG9mIGRp c2N1c3Npb24gJiBkZWJhdGUgd2l0aGluIHRoZSBJRVRGIC0tIGFuZCBJIHJlbWFpbiBob3BlZnVs IHRoYXQgd2Ugd2lsbCBjb250aW51ZSB0byBtYWtlIHBvc2l0aXZlIHN0ZXBzIGZvcndhcmQgdG93 YXJkcyBhIGJldHRlciBhbmQgbW9yZSBvcGVuIElFVEYuDQoNCi0gSmFzb24NCg0KU2VjdGlvbiAz LjIuICBTbWFsbCBCZW5lZml0LCBQb3RlbnRpYWxseSBMYXJnZSBDb3N0DQotIEkgZG9u4oCZdCB0 aGluayB5b3UgaGF2ZSBlc3RhYmxpc2hlZCBvciBxdWFudGlmaWVkIHRoYXQgdGhlcmUgaXMgYWN0 dWFsbHkgbXVjaCwgaWYgYW55LCBjb3N0IG9mIGVtYWlsIGRpc2N1c3Npb24gb2YgdGVybWlub2xv Z3ksIG5vciB0aGF0IHRoaXMgc3VwcG9zZWQgJ2VuZXJneSBkcmFpbicgb24gdGhlIElFVEYgaXMg ZWl0aGVyIHNpZ25pZmljYW50IG9yIG5lZ2F0aXZlbHkgYWZmZWN0cyB0aGUgd29yayBvZiB0aGUg SUVURi4NCi0gWW91IGRlc2NyaWJlIHRoZSBjaGFuZ2VzIGluIHRlcm1pbm9sb2d5IChlLmcuIGNo YW5naW5nIG1hc3Rlci1zbGF2ZSB0byBwcmltYXJ5LXNlY29uZGFyeSkgYXMgYSBzbWFsbCBiZW5l Zml0LiBJIGFyZ3VlIHRoYXQgaXQgaXMgYWN0dWFsbHkgaHVnZWx5ICYgc3ltYm9saWNhbGx5IGlt cG9ydGFudCBhcyBhIHBhcnQgb2YgYSByYW5nZSBvZiBjcml0aWNhbCAmIG5lY2Vzc2FyeSBzdGVw cyB0b3dhcmRzIGdyZWF0ZXIgb3Blbm5lc3MsIGluY2x1c2l2ZW5lc3MsIGFuZCBhdHRyYWN0aW9u L3JldGVudGlvbiBvZiBuZXdjb21lcnMuIEFzIGEgcmVzdWx0LCBJIHN1Z2dlc3QgdGhhdCBpZiB5 b3UgbG9vayBhdCB0aGUgYmlnZ2VyIHBpY3R1cmUgYW5kIHRoZSBjb3N0L2JlbmVmaXQgb2YgYWN0 aW9uIG9yIGluYWN0aW9uIG9uIHRoaXMgbmFycm93IGlzc3VlIG9mIHRlcm1pbm9sb2d5IHRoYXQg dGhlIGJlbmVmaXQgb2YgYWN0aW9uIGlzIHNpZ25pZmljYW50IGFuZCB0aGUgY29zdCBvZiBpbmFj dGlvbi9pbnRyYW5zaWdlbmNlIGlzIGFsc28gc2lnbmlmaWNhbnQuDQoNClNlY3Rpb24gMy4zLiBQ b3RlbnRpYWwgRm9yIFVucHJvZHVjdGl2ZSBEaXN0cmFjdGlvbg0KLSBJIHRoaW5rIGl0J3MgYSBz dHJldGNoIHRvIHN1Z2dlc3QgdGhhdCB0aGUgcmVhc29uIFJGQ3MgdGFrZSBzbyBsb25nIHRvIHB1 Ymxpc2ggaGFzIGFueXRoaW5nIHRvIGRvIHdpdGggZXhjbHVzaW9uYXJ5IGxhbmd1YWdlIG9yIHRo YXQgdGhpcyB3b3VsZCBleGFjZXJiYXRlIHRoZSBzaXR1YXRpb24gb2YgcHVibGlzaGluZyBSRkNz LiBTZWUgZm9yIGV4YW1wbGUgYSByZWNlbnQgYmxvZyBhYm91dCBSRkMgdGltZXMgYXQgaHR0cHM6 Ly9ibG9nLmFwbmljLm5ldC8yMDIwLzA4LzI1L29waW5pb24tdGhlLW1ha2luZy1vZi1hbi1yZmMt aW4tdG9kYXlzLWlldGYvLg0KLSBDb21wYXJpbmcgd2hldGhlciBhIHRlY2huaWNhbCBzcGVjaWZp Y2F0aW9uIGluIGFuIFJGQyAiU0hPVUxEIiBvciAiTVVTVCIgYmUgcmVxdWlyZWQgaW4gYSBzdGFu ZGFyZCB0byB3aGV0aGVyIHRvIGNvbnRpbnVlIHVzaW5nICJtYXN0ZXItc2xhdmUiIGluc3RlYWQg b2YgInByaW1hcnktc2Vjb25kYXJ5IiBkb2VzIG5vdCBtYWtlIHNlbnNlIHRvIG1lLg0KDQpTZWN0 aW9uIDMuNC4gIExhdGUgU3Vic3RpdHV0aW9uIG9mIFdvcmRzIENvbnNpZGVyZWQgSGFybWZ1bA0K LSBJIGRvbid0IHRoaW5rIHRoZXJlJ3MgYSByaXNrIG9mIGNvbmZ1c2luZyByZWFkZXJzIGJ5IGRv aW5nIHRoaW5ncyBsaWtlIHNlZWtpbmcgdG8gY2hhbmdlIGZyb20gIm1hc3Rlci1zbGF2ZSIgdG8g InByaW1hcnktc2Vjb25kYXJ5Ii4NCi0gTGF0ZSBzdWJzdGl0dXRpb24gY2FuIGJlIGF2b2lkZWQg Y29tcGxldGVseSBieSBkb2N1bWVudGluZyBhbmQgY29udGludWluZyB0byBkb2N1bWVudC9kaXNj dXNzIHRlcm1pbm9sb2d5IHRoYXQgY2FuIGJlIHByb2JsZW1hdGljLg0KDQpTZWN0aW9uIDQuMS4g UkZDIEVkaXRvciBSZXF1ZXN0ZWQgVG8gQWR2aXNlIENvbW11bml0eSBBYm91dCBQb3RlbnRpYWxs eSBFeGNsdXNpb25hcnkgTGFuZ3VhZ2UNCi0gSSBhZ3JlZSB0aGF0IHRoZSBSRkMgU3R5bGUgR3Vp ZGUgaXMgb25lIG9mIHRoZSBwb3NzaWJsZSB0b29scyB0byBhZGRyZXNzIHRoZXNlIGlzc3VlcyAo dGhvdWdoIHBlcmhhcHMgbm90IHRoZSBvbmx5IHBvdGVudGlhbCB0b29sKS4NCg0KU2VjdGlvbiA0 LjIuICBDb21wbGFpbnRzIFByZWZlcnJlZCBGcm9tIEFnZ3JpZXZlZCBQYXJ0aWVzDQotIEFzIG90 aGVycyBoYXZlIHN0YXRlZCwgdGhlIGVudGlyZSBJRVRGIG9yIGF0IGxlYXN0IGEgd2lkZSByYW5n ZSBvZiBwYXJ0aWNpcGFudHMgb3IgZXZlbiBwb3RlbnRpYWwgcGFydGljaXBhbnRzIGNhbiBiZSBh ZmZlY3RlZCBieSBhbiBpc3N1ZS4gSXQgc2VlbXMgdW5mYWlyIHRvIHBsYWNlIHRoZSBzb2xlIGJ1 cmRlbiBvbiB0aGVtIHdoZW4gd2UgYXMgYSBjb21tdW5pdHkgY2FuIHRha2UgdGhlIHNpbXBsZSBz dGVwcyB0byBjaGFuZ2UgdGhpcyBsaWtlICJtYXN0ZXItc2xhdmUiIHRvICJwcmltYXJ5LXNlY29u ZGFyeSIuIEFzIHdlbGwsIHdlIG5lZWQgdG8gY29uc2lkZXIgdGhlIHBpcGVsaW5lIG9mIGZ1dHVy ZSBwb3RlbnRpYWwgbmV3Y29tZXJzIHdobyBtYXkgc2VlIHRoZSBzdHViYm9ybiBwZXJwZXR1YXRp b24gb2Ygc3VjaCB0ZXJtcyBhcyBhIGNsZWFyIHNpZ25hbCB0aGF0IHRoZWlyIHBhcnRpY2lwYXRp b24gaXMgbm90IHdlbGNvbWUgb3IgZGVzaXJlZCwgc28gaG93IHdvdWxkIHRoZXkgcmFpc2Ugc3Vj aCBhbiBpc3N1ZSBpZiB0aGV5IGhhdmUgYmVlbiByZXBlbGxlZCBmcm9tIHBhcnRpY2lwYXRpb24g aW4gdGhlIGZpcnN0IHBsYWNlPw0KDQpTZWN0aW9uIDQuNS4gIFdvcmtpbmcgR3JvdXAgQ2hhaXJz IE1heSBMaW1pdCBEaXNjdXNzaW9uIG9mIExhbmd1YWdlDQotIElmIGEgV0cgZm9sbG93cyB0aGlz IGFkdmljZSB0aGVuIHRoZXkgc2VlbSB0byBjcmVhdGUgdGhlIGNvbmRpdGlvbnMgeW91IHdvcnJ5 IGFib3V0IGluIFNlY3Rpb24gMy40LiAgTGF0ZSBTdWJzdGl0dXRpb24gb2YgV29yZHMgQ29uc2lk ZXJlZCBIYXJtZnVsLiBJTU8gdGhlIHNvb25lciBhbnkgcHJvYmxlbWF0aWMgaXNzdWVzIHdpdGgg YSBkcmFmdCBhcmUgcmFpc2VkLCB0aGUgYmV0dGVyLCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhv c2UgYXJlIHRlY2huaWNhbCBvciBub24tdGVjaG5pY2FsLiBJIGNhbiB0ZWxsIHlvdSBmcm9tIG15 IHBlcnNvbmFsIGV4cGVyaWVuY2Ugd3JpdGluZyBkcmFmdHMgdGhhdCB0aGUgc29vbmVyIEkgaGVh ciBvZiBhIGNvbmNlcm4gdGhlIGJldHRlciBhbmQgZmFzdGVyIGFuZCBtb3JlIGVhc2lseSB0aGF0 IEkgY2FuIGRlYWwgd2l0aCBpdC4NCg0KU2VjdGlvbiA0LjcuICBCbG9ja2luZyBCYXNlZCBPbiBM YW5ndWFnZSBNdXN0IGJlIEJhc2VkIE9uIElFVEYgQ29uc2Vuc3VzDQotIFRoaXMgc2VlbXMgYXQg b2RkcyB3aXRoIHlvdXIgU2VjdGlvbiA0LjEuIE9uIHRoZSBvbmUgaGFuZCB5b3Ugc2VlbSB0byBz dWdnZXN0IHRoZSByaWdodCBhcHByb2FjaCBpcyBzb2xlbHkgdmlhIHRoZSBSRkMgU3R5bGUgR3Vp ZGUgYnV0IG9uIHRoZSBvdGhlciBoYW5kIHNheSBub3RoaW5nIGNhbiBiZSBkb25lIGFic2VudCBh biBSRkMuDQoNClNlY3Rpb24gNC45LiAgTm8gUmVxdWlyZW1lbnQgVG8gUmV2aXNlIEV4aXN0aW5n IFJGQ3MNCi0gVGhlIElFVEYgdXBkYXRlcyBSRkNzIGFuZCBCQ1BzIGFsbCB0aGUgdGltZSwgZXZl biBmb3IgbGltaXRlZCByZXBsYWNlbWVudC91cGRhdGUgb2Ygc3BlY2lmaWMgdGVybXMuIFdlIGp1 c3QgZGlkIGEgYnVuY2ggb2YgdGhvc2Ugd2hlbiB0cmFuc2l0aW9uaW5nIGZyb20gdGhlIElBT0Mg dG8gdGhlIExMQyBmb3IgZXhhbXBsZSwgYW5kIGl0IHdhcyBmYWlybHkgZWFzeS4NCi0gQXMgd2Vs bCwgd2h5IHdvdWxkIHdlIHdhbnQgdG8gcGVycGV0dWF0ZSBmb3IgYWxsIHRpbWUgdGhlIHVzZSBv ZiAibWFzdGVyLXNsYXZlIiB3aGVuIHN1Y2ggYSBzaW1wbGUgY2hhbmdlIHRvICJwcmltYXJ5LXNl Y29uZGFyeSIgaXMgcG9zc2libGU/DQoNCjxlb20+DQoNCu+7v09uIDgvMjYvMjAsIDg6MjcgUE0s ICJHZW5kaXNwYXRjaCBvbiBiZWhhbGYgb2YgS2VpdGggTW9vcmUiIDxnZW5kaXNwYXRjaC1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtb29yZUBuZXR3b3JrLWhlcmV0aWNzLmNvbT4gd3Jv dGU6DQoNCiAgICBPaywgYWZ0ZXIgdGhlIHVzdWFsIG1hbnkgaG91cnMgb2Ygd3JhbmdsaW5nIHdp dGggdGhlIGktZCBzdWJtaXNzaW9uDQogICAgdG9vbHMsIG15IGRyYWZ0IGlzIGZpbmFsbHkgcG9z dGVkLg0KDQogICAgQXQgbGVhc3QgaW4gdGhpcyBmb3JtIEknbSBpbnRlbmRpbmcgdGhpcyBkcmFm dCB0byBiZSBtb3JlIG9mIGEgdG9waWMgZm9yDQogICAgZGlzY3Vzc2lvbiB0aGFuIGEgY2FuZGlk YXRlIGZvciBwdWJsaWNhdGlvbi4NCg0KICAgIEkgbG9vayBmb3J3YXJkIHRvIHRoZSByZWFsLXRp bWUgbWVldGluZy4NCg0KICAgIEtlaXRoDQoNCg0KDQo= From nobody Thu Aug 27 10:50:06 2020 Return-Path: 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 DA3383A11CF for ; Thu, 27 Aug 2020 10:49:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 6I7TLLSbiC9R for ; Thu, 27 Aug 2020 10:49:58 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7373A11C9 for ; Thu, 27 Aug 2020 10:49:57 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 312695C0292; Thu, 27 Aug 2020 13:49:57 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 27 Aug 2020 13:49:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=+pp4jDI0D22p7C3Q6GM9BMMAWZryDc/2A0RMAA1E6 ho=; b=aILjoZEtaQu78JaNmQpN758nVl9CcTW0gdHwRlQwPlV62vhisAajHaWgm b1nvukpH2AJzAXO5A+LOKO+yv2Oba6TYDpuLiZ5K3qXmQKDW5uooRBjuksFeHsB5 S74pbleO8xV/oWwOsfA9auTA8Dj1sp+7LyixlExLn8Dj2lOQWiudyNLsnjaCu8h1 dmCml/uHJrTCCYa6miWnqUstYP7ndKVOR+mjn+f5AI7jJhmQfOf52PJKeLNqIsuW MkATYJbA3uya7XO7X0ezg5AVrYdgf8UXBRI9MKUoIvIoh04mG2E7TMMukIwYvzNB rxcolLJV0K4MgNtFY4TUhzqjVfwrQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvgedguddugecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpefmvghi thhhucfoohhorhgvuceomhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtoh hmqeenucggtffrrghtthgvrhhnpeehhfeutdehfefgfefghfekhefguefgieduueegjeek feelleeuieffteefueduueenucfkphepuddtkedrvddvuddrudektddrudehnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhrvgesnhgv thifohhrkhdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 754E030600B2; Thu, 27 Aug 2020 13:49:56 -0400 (EDT) To: "Livingood, Jason" , "gendispatch@ietf.org" References: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> <8BD7761E-0DD0-4B1B-88FD-51FD5DAE3683@cable.comcast.com> <6572756a-4679-79b6-8f40-ebc2b748b2d4@network-heretics.com> <6AEF509D-A5AE-4AB4-80F5-9B99EDEA66C3@cable.comcast.com> From: Keith Moore Message-ID: Date: Thu, 27 Aug 2020 13:49:54 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <6AEF509D-A5AE-4AB4-80F5-9B99EDEA66C3@cable.comcast.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 17:50:05 -0000 On 8/27/20 1:21 PM, Livingood, Jason wrote: > (personal views - no hats - see inline) > > On 8/27/20, 11:14 AM, "Gendispatch on behalf of Keith Moore" wrote: > >> But to clarify, the potential disruption I anticipate and want to avoid would probably be due to any of: >> (a) interminable or repeated arguments about whether it's ok to ban or even discourage particular terms (like "master") for which there's little etomologic justification and a large potential loss in terms of readability if the term were banned; > [JL] This seems diversionary - the discussion has focused on replacing master-slave with something like primary-secondary. There are simple terms for which I suspect rough consensus exists. Are you arguing that you favor retaining master-slave? I am somewhat doubtful that rough consensus exists on that, particularly if we extend the discussion across all of IETF and not bury it within gendispatch.   I actually think the best choice might differ on a case-by-case basis. For instance, if we're talking about database replicas in single-master databases, I'd be fine with primary-replica as IMO it's actually more descriptive and the substitution can be made with little or no loss in clarity.   But I don't feel comfortable making that judgment about all potential uses of master-slave, because "master" and "slave" actually mean different things in different cases and it's not always clear that there's a good substitute. Also, these are not always simple terms, and there are potential ripple effects from such changes.  What if we're talking about what are currently called "multi-master" databases that do conflict resolution without reference to a single primary copy? "primary-replica" is an easy substitution for the single master database, but "multi-primary" doesn't sound right at all to me. I'm not saying this problem can't be sorted out, but it's not something that should be imposed from on high. What we're discussing here is whether we should cripple the language that we use to communicate subtle technical concepts to others.   There are real costs to changing our language that should not be summarily dismissed.   And the idea that somehow we should just make a blanket decision for how to change things, or even which words to avoid, that makes sense across every subject domain in IETF seems like a huge stretch. > > > (b) the possibility of documents being arbitrarily blocked by IESG over the documents' use of certain words, without the backing of community consensus; or >> (c) documents held up interminably (in a WG or anywhere else) over disputes about terminology. > [JL] Those both seem like a stretch but in any case the IETF has well-worn processes to sort out publishing documents. I don't think you have made the case for significant disruption. IMO, disruption is exactly what bringing up this whole issue has caused, and the leadership's response has been to try to sweep the whole issue under a rug. Keith From nobody Thu Aug 27 10:56:14 2020 Return-Path: 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 8D9903A11A3 for ; Thu, 27 Aug 2020 10:56:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.948, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 wSr2wx5WDfIi for ; Thu, 27 Aug 2020 10:56:09 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD9953A11E4 for ; Thu, 27 Aug 2020 10:56:01 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QFQ1Q8TUHTD4Y@wwwlocal.goatley.com> for gendispatch@ietf.org; Thu, 27 Aug 2020 12:56:01 -0500 (CDT) Received: from blockhead.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QFQ00IM1HR56P@trixy.bergandi.net> for gendispatch@ietf.org; Thu, 27 Aug 2020 10:54:42 -0700 (PDT) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO blockhead.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Thu, 27 Aug 2020 10:54:42 -0700 Date: Thu, 27 Aug 2020 10:55:58 -0700 From: Dan Harkins In-reply-to: <1cdb07cf-4cd5-7f29-3c2c-78bb086e1816@digitaldissidents.org> To: gendispatch@ietf.org Message-id: <37399408-8c4f-fdc1-d4b9-71e6a2bb40f9@lounge.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO blockhead.local) References: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> <9584b8b1-a4dd-5a41-ffba-93df5d780f23@network-heretics.com> <6f296d9f-6b5e-9caf-71f3-77467140fc1e@network-heretics.com> <1cdb07cf-4cd5-7f29-3c2c-78bb086e1816@digitaldissidents.org> X-PMAS-Software: PreciseMail V3.3 [200827] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 17:56:13 -0000 On 8/27/20 3:45 AM, Niels ten Oever wrote: > Dear Keith, > > On 8/27/20 12:34 PM, Keith Moore wrote: >> On 8/27/20 6:31 AM, Niels ten Oever wrote: >> >>>> Other communities have different purposes and different rules. I don't want to dissect each community and try to analyze how each one manages its internal conflicts, or whether the narrow scope of the community afforded them some insulation from potential controversy not afforded to IETF, and gauge how predictive each community's experience would be for IETF.  We don't need to resort to dubious analogies, we have already witnessed firsthand a small taste of how this specific discussion can be disruptive to IETF. >>> You are comparing the discussion about such measures with how they would be implemented. I do not think that's fair. The assumptions you make about the potential disruptive impact, which is the main reason for _not_ changing anything and rather erring on the side of the status quo and exclusionary language, are not very much substantiated. Neither in theory, nor in practice. >> Well, I'm not arguing for not changing anything.  I'm arguing for changing things but with due care.    And I trust my 30-year experience in IETF over the mere assertions of someone else. >> > The problem is, I am not making assertions. The whole of draft-knodel-terminology has been based on research. Whereas draft-moore-exclusionary-language and draft-gondwana-effective-terminology do not back up their claims with literature or data. That does not seem a very scientific or engineering way to go about it to me. But of course, happy to discuss.   draft-knodel-terminology refers to papers behind paywalls which makes evaluation of the claims made pretty much impossible. Not all "research" is scientific and much of it cannot be reproduced [1]. This is especially true of research into social sciences, which is what you are referencing, that is plagued by small sample size, high variability, and selection bias.   And you are making assertions. You assert that a metaphor is exclusionary but don't say who is excluded and why. Happy to discuss? Start there.   You talk about the "scientific or engineering way" but then in [2] you say, "What we are currently doing is excluding people from the conversation - we only have to look at the composition of our community to confirm that." There is absolutely nothing scientific about that claim. There may be multiple factors involved in creating the composition of a community that is constantly in flux. To take a snapshot and attribute language to be the cause of it's current make-up is decidedly un-scientific. Would you attribute the make-up of the National Basketball Association (NBA) in the USA-- upwards of 75% of the NBA is black while blacks make up only 13% of the population of the USA-- to some exclusionary factor? No, of course not. So don't try and use the make-up of the IETF as proof that some language you don't like is exclusionary. That's not scientific.   Dan. [1] https://www.westburg.eu/blog/having-hard-times-reproducing-your-experiments [2] message-id From nobody Thu Aug 27 11:12:34 2020 Return-Path: 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 AE49E3A11C4 for ; Thu, 27 Aug 2020 11:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=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=comcast.com header.b=qSIoacrV; dkim=pass (2048-bit key) header.d=comcast.com header.b=VUwoo+Hy; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=pJdVypH9 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 fn_XuhwxNFS0 for ; Thu, 27 Aug 2020 11:12:27 -0700 (PDT) Received: from mx0a-00143702.pphosted.com (mx0a-00143702.pphosted.com [148.163.145.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFCED3A11AA for ; Thu, 27 Aug 2020 11:12:27 -0700 (PDT) Received: from pps.filterd (m0184894.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07RIAcZt020959 for ; Thu, 27 Aug 2020 14:12:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=U1Ykwq08diKHkMWXq0+AXRK/UJp3D4LEzjttkLnUwFY=; b=qSIoacrVKYG6yu5x80fuq85oxQoVwPbUbahX5NK1TjeO61YSDhr/ldfbRZkjl+VqAaKU 227GuaErDPlfiRs0Phd2W6MsTK60NHA817McuhvA4v3FrMPFV4NbAqEw9NbzLvkZWUJw LLyr/owabHASaxArOpT5/Qu71aGC97/LU7eeEF4OuTG9WyqomjLJPRQTaCyv/jGNpjeP YFldSXC/1aknGahfAQuYApFTiC0P97yMHNKaj3ygmUsy7c1oNp3PQ8Rl5hPISLtC6tCC M5op0SXtTqyXMeTOnDNiIfRWKbozVVIQMW9ZIO/J8oEpB7hj+sgHfEQPv+cyZ18DIldm Iw== Received: from pacdcmhout02.cable.comcast.com (pacdcmhout02.cable.comcast.com [68.87.96.15]) by mx0a-00143702.pphosted.com with ESMTP id 332vnwcv2h-22 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 27 Aug 2020 14:12:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1598551942; x=2462465542; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=U1Ykwq08diKHkMWXq0+AXRK/UJp3D4LEzjttkLnUwFY=; b=VUwoo+Hy5RwF6xUctj4oQmC4hmecwmAqXbYO302t5IreEaNR9kq6kA7qZ/MFiISm 4EgMaBhSBzYrdIuGI01zFdWBxdiPorUOaVWYW7TAo/g5FhDDH7wx8QXFjYUwliZz 6ZEYcrtu+nz58EFsdVK2mOnzsGEr1OI5Kg0irngvH3LubUN0Cmkmw70VA/qb3oQ6 ivf3vdcAxsFGnjS/xHQD5RQ+Esuy05iyM+PrHjQTeCyDch8403BtdqtaUSoTAEJ1 U7olGwE1r391u1CYMpeHiWN2GDNDwE+9NDXZQ3JhYQPa3Spb+ekgksM0/vRYdFrS Eb/z2+3eKoICUlj7WIKBig==; X-AuditID: 4457600f-f27ff70000005543-a1-5f47f785139f Received: from PACDCEX55.cable.comcast.com (cas-umc02.ndceast.pa.bo.comcast.net [68.87.34.28]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by pacdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 66.EA.21827.587F74F5; Thu, 27 Aug 2020 14:12:21 -0400 (EDT) Received: from PACDCEX45.cable.comcast.com (24.40.2.144) by PACDCEX55.cable.comcast.com (24.40.2.154) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Aug 2020 14:12:21 -0400 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX45.cable.comcast.com (24.40.2.144) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 27 Aug 2020 14:12:20 -0400 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.177) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Aug 2020 14:12:11 -0400 Received: from MN2PR11MB4287.namprd11.prod.outlook.com (2603:10b6:208:189::17) by BL0PR11MB3393.namprd11.prod.outlook.com (2603:10b6:208:62::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3326.19; Thu, 27 Aug 2020 18:12:10 +0000 Received: from MN2PR11MB4287.namprd11.prod.outlook.com ([fe80::b951:e489:324b:cb3f]) by MN2PR11MB4287.namprd11.prod.outlook.com ([fe80::b951:e489:324b:cb3f%6]) with mapi id 15.20.3305.032; Thu, 27 Aug 2020 18:12:10 +0000 From: "Livingood, Jason" To: Keith Moore , "gendispatch@ietf.org" Thread-Topic: [Gendispatch] Grounding the exclusionary language discussion Thread-Index: AQHWfJ2UIxDJmcL0xkOCcLoIiabXZA== Date: Thu, 27 Aug 2020 18:12:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: network-heretics.com; dkim=none (message not signed) header.d=none;network-heretics.com; dmarc=none action=none header.from=cable.comcast.com; x-originating-ip: [2601:87:4280:7190:34a9:157:896e:48fa] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e7d21d8e-e3d0-419c-d503-08d84ab4b729 x-ms-traffictypediagnostic: BL0PR11MB3393: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kcdTDFZVIxLigTRmCn0fAbXH5wuYygAlQZywmILaoQQQW2kGj8VUUeZC2gcyqcpb8lFPQIXebgh/HmLwebPtEHmZXFFCw2sMk8JMN3NrhjgYtlEhdlqnmcshO2P8UfvMSUz7VwwLiWm+qcR5ZYXQpICGhzWfFYV2NSIguyM6WarkmSVvHr4QlEevEynZ5yDWq4/+S9eNwE8ijJOk99cGRgL9cvVsGwETOjegoen0KuqfA1JvpJVF3JitxvM66GCsm625Dur6+lt2xhdhDN5bXt0Sx+aKeT4ChnSU4uzSM0eb3xeyMeXqnMoG711AquWjlpw4zrSvXQzrVGML+9iTzg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4287.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(376002)(136003)(39860400002)(346002)(396003)(8676002)(6512007)(6486002)(478600001)(110136005)(66446008)(33656002)(186003)(66556008)(6506007)(5660300002)(64756008)(66946007)(316002)(66476007)(76116006)(2616005)(86362001)(2906002)(71200400001)(8936002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: RnQmtoYB/JQF3phrJN8IdVZxWFKZu1oG+rAPUiLvpmv5Wvsf6grdQi4SBIf7jrA+yW1vNUrp82BoE7Pj8Og7ctYe4Umeyi7q3PgezJ4WzwKaS2fBhJYQbghMLDgYhLHQcGpJspjU+DFZuKUC8yyZdJ1nTx/A0mlqAlwgxz8vIhPa808C9PLTITLEeo7SHFermNBxqOr5Q83g/rMja/FVrInckQAu3BXolIgA/Fff1obH4s8/v+W8tZJVBuQuYvKNTAgwr3Yds5FJmeXsKRrIg+wZq9gPqGKxA1U7I6OVTmcKNlVrWRm7++vHIVzE0m0iZSvBL13UbZgt6ftdl857g76ZZUSQW+rSgsJ1wkVovuhWH9TFLS+lnyFDCmfiaIWkXejIUfWAeZhwI55gJvRUeUp2tR26dOor7ioZPPE+rjtqP7dEO/jEUN6meeyCjPTRVQX4utfpfSpyO0w2NaqC9Qrbdavz9F6XENssLGNxeDhQA24DWkppfw4Q4j096wZ0fW1soom4hK0kwU2rKWC6FYJqCUuor6h6tqg2MEGAP1+ZJm8gPZXxMTcgi9cqa7mkfnzI48s+r9c4NgNofo+ACgmVKpf6JJSLZ2xZAelAVDHqIVgRBWltv3jizG74GjS3TJmgsP1sU6Y7C7Owg2BcVjx5Qu5jaIKWjeQpx7dY0fC+HNmmQ8PLtko83EVr5/UeaRWq6R2miqIARbKYiBCKlg== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HeIBANEP0QrXLj6qrR5sSZ0menOrEXhzvMqqtUX+YkyDQzbcOWbgsnKXd5EC/6mHZVy+kukygjUJ1ZiRzfEi2Uk7CVGJCdIJkHvWVAKZDHqtEYy6bA74kebbRxSkD8wHjbexhwxsm3U4S/uqHa7Y3jb9ysrDQJYRjBaaOn+nGMqr9gnQwmCSaT7Si759p2hfMZlY0EQhFsMo/+Nizbb/H5tuiN6H5gMMP0DyxEsgzYEH8n9nonGZyEtU+TUDY9l2eZ5Z+QKYC3BmeH8BXH0u3eySxiW3XBJex8tKA3CQNmRQsDqXNhhG30vi9yCA35dpB/tF6uDawCiZ+84B/+qJUQ== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lHMd5Rc2zi+P6EZNFNWl55zU9jM3YhqbEuyBB8U55FQ=; b=UFg0XMkKiLySEm6JTZrE4t45wVRSAo8zCaBVnD+Fq2rKBbEOFCHK5ZpwwoPYvsoZF+T1J6ejQe4H3hUJEyYTHpeFYiajdt2bL4x0TAJtYCxlRXAVvoc3BNsrno4nl/RQ7mFNshMFK7vGudcpcPs0HoeFYxuRQp6CoFJimmW7oGJquEjCHNIFgVM3UOfiU5J62uR1fk5CAp7OnztknmykEZoDn8O+MeoIbwFJuelKUG/orv2NGmBY5ql+hwAhpAnE7y0HF/8R975ozOo3DckR1532pmwx6GUKQlrjcXCjOFgZ3218lXH078Hbn+8cFvbBEjaDKHcfFspxLwQ72J1yog== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lHMd5Rc2zi+P6EZNFNWl55zU9jM3YhqbEuyBB8U55FQ=; b=pJdVypH9x+Qyu3WSV1Xn/kZ5Lx3LeDKeQTNdAVzT+WF7eFjXMKKWQLfKvHzd2wXFDo3a+O45HRWJvPXBeALvgYxZN6gqGJhU311V9Lmn0xWKtUSyaDoilqX8ZGXW+AcJJR/w6oSeaG6a21YEcF8nUZqsLkUy03Ramz5K77e7T7A= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4287.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: e7d21d8e-e3d0-419c-d503-08d84ab4b729 x-ms-exchange-crosstenant-originalarrivaltime: 27 Aug 2020 18:12:09.9316 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: 0MkfavcNICGNQqceJkL2ly/Xu2RhjiCH2v3KZxJz4dW/d8JLu400qpECvj0/rmaAL6oQuqalnI2R67ysyGlos69I/TJsuZm5wN45yQ5DNQQ= x-ms-exchange-transport-crosstenantheadersstamped: BL0PR11MB3393 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <0D4D71EA8D422D4DBD6C533D989B562A@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42JxCVeS0W377h5vcPkdv8X8hhWsFpO+nmNz YPJYsuQnk8ekE2EBTFFcNimpOZllqUX6dglcGVfOlhc8E6642vyYrYFxiXAXIweHhICJxN9d Il2MXBxCAkeYJNb0dDBDOLsYJbbcvgHlXGWU+DCzjw3COcYocfnqWSYIZwmTxII7h6DKHjFK vP84l7WLkZODTcBM4u7CK8wgtohArMTvsy/ZQWxhAU+Jrr93mUCWiwh4SXx96gxh6knMWJsK UsEioCpx9dphsGpeAReJRVOfsIHYjAJiEt9PrWECsZkFxCVuPZkPZksICEgs2XOeGcIWlXj5 +B/YBaIC+hKvO3aC3ckosAro6Jkv2CCKLCR2Pd/GDmHLSlya380IYftKnL53CqpGS+Lt7K9Q Q7Mlpnx6D1WvJnHjTQdUXE5iVe9DFghbRuLBje3gEJIQ+A0MyC0HoYq2Mkv8W2kGkfjDKvFn /ywmSMirSPw7VDmB0XgWkodmAWWYBTQl1u/Shwh7SNxv2s8KYStKTOl+yD4LHC6CEidnPmFZ wMi6ipHbzELPwlzP0kzP0HQTIzhpJPDvYDw63eMQowAHoxIP7+Vn7vFCrIllxZW5hxglOJiV RHhfHwUK8aYkVlalFuXHF5XmpBYfYpTmYFES5+2/+iJOSCA9sSQ1OzW1ILUIJsvEwSnVwMiy 8R+Xz5Wwebf3f1I6GeOzVOxBQX//jNBTTRM2TvgXEFkrFn9Nvsm2XeNf14cXqxT2CcnfuXu7 9/aM1dtvzT9wXIP5mo+gcfPbK4k+BlEVM77ujnk8hWXpira/Ny77L5w3+6lK+duby6SeJzu/ 35q5JdXkRvo5Qwbp9yki+fvYBe5ZfvNdfMZSiaU4I9FQi7moOBEAj9RzEhYDAAA= X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-27_10:2020-08-27, 2020-08-27 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 18:12:33 -0000 KHBlcnNvbmFsIHZpZXdzIC0gbm8gaGF0cyAtIHNlZSBpbmxpbmUpDQoNCu+7v09uIDgvMjcvMjAs IDE6NTAgUE0sICJLZWl0aCBNb29yZSIgPG1vb3JlQG5ldHdvcmstaGVyZXRpY3MuY29tPiB3cm90 ZToNCj4gICAgRm9yIGluc3RhbmNlLCBpZiB3ZSdyZSB0YWxraW5nIGFib3V0IGRhdGFiYXNlIHJl cGxpY2FzIGluIHNpbmdsZS1tYXN0ZXINCiAgICBkYXRhYmFzZXMsIEknZCBiZSBmaW5lIHdpdGgg cHJpbWFyeS1yZXBsaWNhIGFzIElNTyBpdCdzIGFjdHVhbGx5IG1vcmUNCiAgICBkZXNjcmlwdGl2 ZSBhbmQgdGhlIHN1YnN0aXR1dGlvbiBjYW4gYmUgbWFkZSB3aXRoIGxpdHRsZSBvciBubyBsb3Nz IGluDQogICAgY2xhcml0eS4gICBCdXQgSSBkb24ndCBmZWVsIGNvbWZvcnRhYmxlIG1ha2luZyB0 aGF0IGp1ZGdtZW50IGFib3V0IGFsbA0KICAgIHBvdGVudGlhbCB1c2VzIG9mIG1hc3Rlci1zbGF2 ZSwgYmVjYXVzZSAibWFzdGVyIiBhbmQgInNsYXZlIiBhY3R1YWxseQ0KICAgIG1lYW4gZGlmZmVy ZW50IHRoaW5ncyBpbiBkaWZmZXJlbnQgY2FzZXMgYW5kIGl0J3Mgbm90IGFsd2F5cyBjbGVhciB0 aGF0DQogICAgdGhlcmUncyBhIGdvb2Qgc3Vic3RpdHV0ZS4NCg0KW0pMXSBJIGRvbuKAmXQgYWdy ZWUgdGhhdCBpdCdzIGFwcHJvcHJpYXRlIHRvIHBlcnBldHVhdGUgdGhlIHVzZSBvZiAnbWFzdGVy LXNsYXZlJyBpbiB0ZWNobmljYWwgc3RhbmRhcmRzIGFuZCBhc3NvY2lhdGVkIGRvY3VtZW50cy4g SSB0aGluayBpdCdzIHRyaXZpYWxseSBlYXN5IHRvIGNoYW5nZSB0byBwcmltYXJ5LXNlY29uZGFy eSBvciBzb21ldGhpbmcgc2ltaWxhciAmIGFtIGNvbmZpZGVudCB0aGF0IGNyZWF0aXZlIG1pbmRz IGNhbiBmaW5kIHdvcmthYmxlIGFsdGVybmF0aXZlcy4NCg0KPiAgICBBbHNvLCB0aGVzZSBhcmUg bm90IGFsd2F5cyBzaW1wbGUgdGVybXMsIGFuZCB0aGVyZSBhcmUgcG90ZW50aWFsIHJpcHBsZQ0K ICAgIGVmZmVjdHMgZnJvbSBzdWNoIGNoYW5nZXMuDQoNCltKTF0gQXMgd2VsbCwgdGhlcmUgYXJl IGxpa2VseSByaXBwbGUgZWZmZWN0cyBmcm9tIG5vdCBtYWtpbmcgY2hhbmdlcyAtIHRoZSBzdGF0 dXMgcXVvIGlzIG5vdCB3aXRob3V0IGNvc3Qgb3IgaXNzdWUuDQoNCj4gV2hhdCBpZiB3ZSdyZSB0 YWxraW5nIGFib3V0IHdoYXQgYXJlDQogICAgY3VycmVudGx5IGNhbGxlZCAibXVsdGktbWFzdGVy IiBkYXRhYmFzZXMgdGhhdCBkbyBjb25mbGljdCByZXNvbHV0aW9uDQogICAgd2l0aG91dCByZWZl cmVuY2UgdG8gYSBzaW5nbGUgcHJpbWFyeSBjb3B5Pw0KDQpbSkxdIE15IHF1ZXN0aW9uIHdhcyBv biB0aGUgbmFycm93IGNoYW5nZSBmcm9tICdtYXN0ZXItc2xhdmUnIHJhdGhlciB0aGFuIGJyb2Fk ZXIgdXNlIG9mICdtYXN0ZXInLiBCdXQgSSdtIHN1cmUgY3JlYXRpdmUgcGVvcGxlIHdpbGwgZGV2 aXNlIG5ldyB0ZXJtcyBvciBjcmVhdGUgbmV3IHdvcmRzIG9yIGFjcm9ueW1zIGFzIHRoZSBJRVRG IGRvZXMgYWxsIHRoZSB0aW1lLiBJRVRGIGNyZWF0aXZpdHkgaXMgYm91bmRsZXNzICYgSSBkb3Vi dCBhIHN0cmFpZ2h0Zm9yd2FyZCB0ZXJtaW5vbG9neSBpc3N1ZSBsaWtlIGNoYW5naW5nICdtYXN0 ZXItc2xhdmUnIHRvICdwcmltYXJ5LXNlY29uZGFyeScgaXMgZ29pbmcgdG8gYmUgaW5zdXJtb3Vu dGFibGUuDQoNCj4gICBUaGVyZSBhcmUgcmVhbCBjb3N0cyB0byBjaGFuZ2luZyBvdXIgbGFuZ3Vh Z2UgdGhhdCBzaG91bGQgbm90IGJlIHN1bW1hcmlseQ0KICAgIGRpc21pc3NlZC4NCg0KW0pMXSBM aWtld2lzZSwgdGhlcmUgYXJlIGNvc3RzIHRoYXQgYXJpc2UgZnJvbSBub3QgY2hhbmdpbmcgbGFu Z3VhZ2Ugd2l0aCB0aGUgdGltZXMuDQoNCg== From nobody Thu Aug 27 11:28:55 2020 Return-Path: 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 7BD6A3A11CB for ; Thu, 27 Aug 2020 11:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 XHj_XVBVajMr for ; Thu, 27 Aug 2020 11:28:52 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4625E3A11CA for ; Thu, 27 Aug 2020 11:28:52 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 2937A10F8; Thu, 27 Aug 2020 14:28:51 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 27 Aug 2020 14:28:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=CUrLkLny15eYGSQMPb4AdCBUHWHnGV8HUjKlkl4Fr gQ=; b=cweQlbF20/NirW24kF4zoTl68OnMyvGyfO4qWiXvp2BOpGBPhWWS8AkjV kY7d7f6Y7K+m9lti7LiXqCytLszCDxkfJqP8QkrgopQ0iAYlGX8ufdXqxD+kZz5B TZMYjryqMrSBPXpxbYggyexK/YNal41/ZtdPZJiImSNF71S+zWBzHRvpNmRJWZSz vSC4YzHGDeqfWaWaNX2UAETVb/Oh+Mj7UZO+t4TkfrZWSvsTXc6tx+fdwbbFdu5R 3UrJocoWAwu7fjxoDw5jIoriSblKhUGeeNqxC/OVEMouduUcqjlP+r9u7fM2E6rU emw6EiaA4aVhGO2JHeQ0TxtOQzHGg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvgedguddvudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpefmvghi thhhucfoohhorhgvuceomhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtoh hmqeenucggtffrrghtthgvrhhnpeehhfeutdehfefgfefghfekhefguefgieduueegjeek feelleeuieffteefueduueenucfkphepuddtkedrvddvuddrudektddrudehnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhrvgesnhgv thifohhrkhdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id DF93430605C8; Thu, 27 Aug 2020 14:28:49 -0400 (EDT) To: "Livingood, Jason" , "gendispatch@ietf.org" References: From: Keith Moore Message-ID: Date: Thu, 27 Aug 2020 14:28:48 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 18:28:53 -0000 On 8/27/20 2:12 PM, Livingood, Jason wrote: > [JL] I don’t agree that it's appropriate to perpetuate the use of 'master-slave' in technical standards and associated documents. I think it's trivially easy to change to primary-secondary or something similar & am confident that creative minds can find workable alternatives. I emphatically disagree about it being "trivially easy", and I don't think you've supported your argument at all. >> Also, these are not always simple terms, and there are potential ripple effects from such changes. >> >> [JL] As well, there are likely ripple effects from not making changes - the status quo is not without cost or issue. Granted, though it might be harder to clearly see the ripple effects from maintaining the status quo.  But I'm not arguing to maintain the status quo, I'm just arguing that we need to be careful about what we change and how we do it. >> What if we're talking about what are currently called "multi-master" databases that do conflict resolution without reference to a single primary copy? >> >> [JL] My question was on the narrow change from 'master-slave' rather than broader use of 'master'. But I'm sure creative people will devise new terms or create new words or acronyms as the IETF does all the time. IETF creativity is boundless & I doubt a straightforward terminology issue like changing 'master-slave' to 'primary-secondary' is going to be insurmountable. I doubt it's insurmountable either, but it does argue that changes should not be imposed by fiat from on high.   IETF creativity is boundless, but measures like this could stifle creativity if not done carefully.  Nothing stifles creativity as much as a loss of agency. >> There are real costs to changing our language that should not be summarily dismissed. >> >> [JL] Likewise, there are costs that arise from not changing language with the times. What did I say that made you think I would disagree with this? This isn't (at least in my mind) an all-or-nothing decision. Keith From nobody Thu Aug 27 12:34:30 2020 Return-Path: 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 1DCB33A124D for ; Thu, 27 Aug 2020 12:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.843 X-Spam-Level: X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 0Gif087MdGu6 for ; Thu, 27 Aug 2020 12:34:26 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E92583A124B for ; Thu, 27 Aug 2020 12:34:25 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 8A019FA9; Thu, 27 Aug 2020 15:34:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 27 Aug 2020 15:34:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; 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=fm3; bh=zcymjf ilYjXCkzveb1mBXQeonQkzo1QBYOScDV7VPoA=; b=F477+BUzbP1j21uWtgJvS2 lGUx9OaVrSAyaHUtbZmGvMTSgh6jyj0GCoj6FgEaCDlZeA1WMIwqXpxTbWn2ul+O 2FpmIRusE603g6/yK5gAgHYbJFy+3mZ+fjaaOrkjqGkfpnute+3excmwoOIxXTlp V08aioGSugVsS69/uBgk4EjYkHFph8+yUJWCbqK+J1KpaHfmsgWHGKIoy569eTxu lOsBJ+Jgd89LCFIjCJfVqcrjM7qYbRFCLkO9nZlSxrNz2EUfLi2Xp/IdRT3Yv6Gp 3JKcNMV/iOPjL8rkO1CJzpoFfWBOnWFMZivfbww/F8BICsrNjvOqtkT8++EWy40A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddvhedguddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepuffvfhfhkffffgggjggtsegrtderredtfeejnecuhfhrohhmpefmvghithhh ucfoohhorhgvuceomhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhmqe enucggtffrrghtthgvrhhnpeeijeeuvdfguefhjeffueehhfefteettefhveeggedvledt udeuueevheegleetjeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdgrphhnihgtrd hnvghtnecukfhppedutdekrddvvddurddukedtrdduheenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvg hrvghtihgtshdrtghomh X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 569BB30600A9; Thu, 27 Aug 2020 15:34:23 -0400 (EDT) To: "Livingood, Jason" , "gendispatch@ietf.org" References: <159848790676.31401.17151257967664129305@ietfa.amsl.com> <09E7A82D-EDC6-4DC8-8B9E-4FCB4F4C81A7@cable.comcast.com> From: Keith Moore Message-ID: Date: Thu, 27 Aug 2020 15:34:21 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <09E7A82D-EDC6-4DC8-8B9E-4FCB4F4C81A7@cable.comcast.com> Content-Type: multipart/alternative; boundary="------------5530D409EE366750BD0F1B10" Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] Fwd: New Version Notification for draft-moore-exclusionary-language-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 19:34:29 -0000 This is a multi-part message in MIME format. --------------5530D409EE366750BD0F1B10 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 8/27/20 1:21 PM, Livingood, Jason wrote: > Here are some comments on your draft, as you requested. While there are aspects of these drafts with which I do not agree, having different I-Ds to consider is an important part of the process of discussion & debate within the IETF -- and I remain hopeful that we will continue to make positive steps forward towards a better and more open IETF. > > - Jason > > Section 3.2. Small Benefit, Potentially Large Cost > - I don’t think you have established or quantified that there is actually much, if any, cost of email discussion of terminology, nor that this supposed 'energy drain' on the IETF is either significant or negatively affects the work of the IETF. I don't think anyone has convincingly established or quantified the benefit of changing the language either. I'm not saying we shouldn't make any changes;  I think we can and should try to improve the language that we use.   Several of the examples on https://github.com/ietf/terminology are words for which I can easily say "yeah, we should probably stop using that word" simply /because it's the right thing to do/ (especially for words that are clearly disparaging of some group).  I'm just not sure how much actual benefit will result. I suspect it will always be hard to measure that benefit, even decades from now. At the same time I expect that there will be many occasions in which a change in terms will be uncontroversial,  particularly if the change is originated by subject matter experts rather than imposed from on high.  IMO the community will willingly avoid using most (but not all) of the terms on the https://github.com/ietf/terminology list as long as individual working groups or areas are given the choice of whether and how to do so.    (And there's certainly some value in aligning use of terms between different standards, so some coordination between groups dealing with the same subject matter would seem appropriate). But I don't think that applies to every word on that list, or every word that someone might come up with, nor do I think there will always be easy/good substitutes. As for energy drain, I feel like anyone who has been around IETF for very long should realize that there are some kinds of hot button issues that have a strong tendency to generate far more heat than light.  Censorship certainly seems like one such issue. Also, many disputes in IETF get resolved because there's an objective technical benefit to the approach chosen, over other identified approaches.   IMO, the use of language is not an issue that uniformly lends itself to that kind of conflict resolution. > - You describe the changes in terminology (e.g. changing master-slave to primary-secondary) as a small benefit. I argue that it is actually hugely & symbolically important as a part of a range of critical & necessary steps towards greater openness, inclusiveness, and attraction/retention of newcomers. As a result, I suggest that if you look at the bigger picture and the cost/benefit of action or inaction on this narrow issue of terminology that the benefit of action is significant and the cost of inaction/intransigence is also significant. You seem to be repeatedly citing a single, easy example to argue something much broader.   I think the cost of changing terms will differ from one term to another and one subject domain to another.  So I find an argument of the form "changing master-slave is easy" (which is actually not clear) "...therefore changing all terms will be easy" unconvincing. I do acknowledge the potential for benefit, especially over the long term.  I also suspect that the benefit may compound over time, and decades from now the benefit may be far more apparent than it will be in say 5-10 years.  But I think it's hard to quantify "symbolically important" benefits. But more broadly, people have spoken of "fixing" long term injustices that we really cannot fix with these small actions.  By saying the benefit is small, part of what I'm saying is that it's small in comparison to the changes that need to happen elsewhere in society. Something that I firmly believe, but didn't really touch on much in my draft, is that (even though we should make at least some of these changes), /we should //not//make these changes in order to feel better about ourselves as privileged persons/.  Because if that's our goal, then we're very likely to get the solutions wrong, all while patting ourselves on our collective backs for our noble efforts.   That's part of why I said we should approach this with humility.  It's also part of why I said that the complaints should ideally come from the parties actually aggrieved by our language, rather than from people claiming to act on those parties' behalf.      Because both the harm done, and the degree of change needed to remedy that harm, will probably be clearer to those parties. > Section 3.3. Potential For Unproductive Distraction > - I think it's a stretch to suggest that the reason RFCs take so long to publish has anything to do with exclusionary language or that this would exacerbate the situation of publishing RFCs. See for example a recent blog about RFC times at https://blog.apnic.net/2020/08/25/opinion-the-making-of-an-rfc-in-todays-ietf/. Oh, I certainly didn't intend to argue that.   What I would say instead is that RFCs get held up for a wide variety of reasons, some of them arbitrarily imposed after a working group has finished.   So I'm arguing against creating more excuses to arbitrarily hold up RFCs. More clearly, I expect IESG to make technical judgments about fitness of protocols.   But I don't think it's appropriate for IESG to be language police, except when following clearly established IETF consensus. > - Comparing whether a technical specification in an RFC "SHOULD" or "MUST" be required in a standard to whether to continue using "master-slave" instead of "primary-secondary" does not make sense to me. It's just a perhaps-familiar example of how people can be overzealous in interpreting rules.   I am not sure why people do it, but I've seen it happen many times.   Maybe some people over-interpret rules out of a desire to show how loyal/obedient they are, but often not a good thing. > Section 3.4. Late Substitution of Words Considered Harmful > - I don't think there's a risk of confusing readers by doing things like seeking to change from "master-slave" to "primary-secondary". I disagree, and again, that one example is not representative of all cases. > - Late substitution can be avoided completely by documenting and continuing to document/discuss terminology that can be problematic. "[A]voided completely" seems like an exaggeration, unless perhaps you have some processes in mind that I'm not aware of.   I do think that late substitution can be minimized if we realize it's a risk that needs to be managed. > Section 4.2. Complaints Preferred From Aggrieved Parties > - As others have stated, the entire IETF or at least a wide range of participants or even potential participants can be affected by an issue. It seems unfair to place the sole burden on them when we as a community can take the simple steps to change this like "master-slave" to "primary-secondary". Again, the trivializing example. But I wasn't intending to "place the sole burden" on anyone. Rather I'm saying that /when people take it upon themselves to be offended on behalf of other people, or to "fix" problems for other people of which they lack personal experience, //they quite often get it wrong//./   One of the ways they get it wrong is by being overzealous, and one of the reasons that people get it wrong is that the people arguing for such changes (often insistently) are trying to make themselves feel better (or more virtuous) rather than actually addressing a harm that they know firsthand through experience. Another way to look at this is: /while discouraging some words in favor of others might be good, discouraging or excluding//more words is not inherently better//, and we don't want to create conditions that enable people to exclude as many words as possible/. > As well, we need to consider the pipeline of future potential newcomers who may see the stubborn perpetuation of such terms as a clear signal that their participation is not welcome or desired, so how would they raise such an issue if they have been repelled from participation in the first place? This argument keeps being made and I've seen no credible support for it.   We need to stop citing this as justification until there's clear evidence to support it.  I'm not saying we shouldn't change our language as there are clearly some cases for which we should.   But other potential changes have significant costs (both in the energy required and in the harm done to the readability of our specifications) and we need to not be making them for dubious reasons. > Section 4.5. Working Group Chairs May Limit Discussion of Language > - If a WG follows this advice then they seem to create the conditions you worry about in Section 3.4. Late Substitution of Words Considered Harmful. IMO the sooner any problematic issues with a draft are raised, the better, regardless of whether those are technical or non-technical. I can tell you from my personal experience writing drafts that the sooner I hear of a concern the better and faster and more easily that I can deal with it. I did say that issues could be raised at any time.    The point is to not have endless discussion about it.   I actually think that if issues are raised early, then there's a good chance that the people raising the issue can work things out with document authors/editors early. I will admit that I'm not sure how best to handle such a discussion if it gets contentious and another proposal for how to do so might be better.   Consider this a placeholder and alternative suggestions are welcome.   Of course, it's not unusual for WG chairs to try to manage discussions that are blocking other progress, or to try to keep the same issues from being raised again and again in the absence of new information. > Section 4.7. Blocking Based On Language Must be Based On IETF Consensus > - This seems at odds with your Section 4.1. On the one hand you seem to suggest the right approach is solely via the RFC Style Guide but on the other hand say nothing can be done absent an RFC. I would draw a distinction between: (a) style advice for use by document authors/editors, including suggestions about which words to avoid and potential substitutes, versus (b) blocking document progress based on presence of certain words.   I'm fine with advice that allows authors/editors some discretion.   But I think IESG should not be able to block or significantly delay documents based on the presence of words, without IETF Consensus to back them up. > Section 4.9. No Requirement To Revise Existing RFCs > - The IETF updates RFCs and BCPs all the time, even for limited replacement/update of specific terms. We just did a bunch of those when transitioning from the IAOC to the LLC for example, and it was fairly easy. Revising many RFCs requires a Herculean effort for often-dubious benefit and IMO we do it far too often.   It's not a matter of just changing a few words.  Every erratum needs to be discussed and resolved.  Often there are long discussions about how to split particular hairs, how to reconcile minor incompatibilities between implementations of the old RFC, implementations of the new RFC, and existing practice that deviates from both.    It's typically necessary to not only sync the revised RFC with everything else that it references (some of which are moving targets).   And there's generally less community interest in doing due diligence on a revised RFC than there was for the original RFC - unless perhaps there are significant bugs to be fixed.   And of course there's the usual WG, IESG, and RFC Editor processing that is done with every RFC.  It hardly seems worth the trouble if there's not a good reason (like an interoperability failure) to change things. So I maintain that gratuitous revision of RFCs is nearly always a Bad Idea.   We should find better ways to update RFCs than by revising them wholesale. Keith --------------5530D409EE366750BD0F1B10 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 8/27/20 1:21 PM, Livingood, Jason wrote:
Here are some comments on your draft, as you requested. While there are aspects of these drafts with which I do not agree, having different I-Ds to consider is an important part of the process of discussion & debate within the IETF -- and I remain hopeful that we will continue to make positive steps forward towards a better and more open IETF.

- Jason

Section 3.2.  Small Benefit, Potentially Large Cost
- I don’t think you have established or quantified that there is actually much, if any, cost of email discussion of terminology, nor that this supposed 'energy drain' on the IETF is either significant or negatively affects the work of the IETF.

I don't think anyone has convincingly established or quantified the benefit of changing the language either.  

I'm not saying we shouldn't make any changes;  I think we can and should try to improve the language that we use.   Several of the examples on https://github.com/ietf/terminology are words for which I can easily say "yeah, we should probably stop using that word" simply because it's the right thing to do (especially for words that are clearly disparaging of some group).  I'm just not sure how much actual benefit will result.   I suspect it will always be hard to measure that benefit, even decades from now.

At the same time I expect that there will be many occasions in which a change in terms will be uncontroversial,  particularly if the change is originated by subject matter experts rather than imposed from on high.  IMO the community will willingly avoid using most (but not all) of the terms on the https://github.com/ietf/terminology list as long as individual working groups or areas are given the choice of whether and how to do so.    (And there's certainly some value in aligning use of terms between different standards, so some coordination between groups dealing with the same subject matter would seem appropriate).  

But I don't think that applies to every word on that list, or every word that someone might come up with, nor do I think there will always be easy/good substitutes.

As for energy drain, I feel like anyone who has been around IETF for very long should realize that there are some kinds of hot button issues that have a strong tendency to generate far more heat than light.  Censorship certainly seems like one such issue. 

Also, many disputes in IETF get resolved because there's an objective technical benefit to the approach chosen, over other identified approaches.   IMO, the use of language is not an issue that uniformly lends itself to that kind of conflict resolution.    

- You describe the changes in terminology (e.g. changing master-slave to primary-secondary) as a small benefit. I argue that it is actually hugely & symbolically important as a part of a range of critical & necessary steps towards greater openness, inclusiveness, and attraction/retention of newcomers. As a result, I suggest that if you look at the bigger picture and the cost/benefit of action or inaction on this narrow issue of terminology that the benefit of action is significant and the cost of inaction/intransigence is also significant.

You seem to be repeatedly citing a single, easy example to argue something much broader.   I think the cost of changing terms will differ from one term to another and one subject domain to another.  So I find an argument of the form "changing master-slave is easy" (which is actually not clear) "...therefore changing all terms will be easy" unconvincing.

I do acknowledge the potential for benefit, especially over the long term.  I also suspect that the benefit may compound over time, and decades from now the benefit may be far more apparent than it will be in say 5-10 years.  But I think it's hard to quantify "symbolically important" benefits.  

But more broadly, people have spoken of "fixing" long term injustices that we really cannot fix with these small actions.  By saying the benefit is small, part of what I'm saying is that it's small in comparison to the changes that need to happen elsewhere in society. 

Something that I firmly believe, but didn't really touch on much in my draft, is that (even though we should make at least some of these changes), we should not make these changes in order to feel better about ourselves as privileged persons.  Because if that's our goal, then we're very likely to get the solutions wrong, all while patting ourselves on our collective backs for our noble efforts.   That's part of why I said we should approach this with humility.  It's also part of why I said that the complaints should ideally come from the parties actually aggrieved by our language, rather than from people claiming to act on those parties' behalf.      Because both the harm done, and the degree of change needed to remedy that harm, will probably be clearer to those parties.

Section 3.3. Potential For Unproductive Distraction
- I think it's a stretch to suggest that the reason RFCs take so long to publish has anything to do with exclusionary language or that this would exacerbate the situation of publishing RFCs. See for example a recent blog about RFC times at https://blog.apnic.net/2020/08/25/opinion-the-making-of-an-rfc-in-todays-ietf/.

Oh, I certainly didn't intend to argue that.   What I would say instead is that RFCs get held up for a wide variety of reasons, some of them arbitrarily imposed after a working group has finished.   So I'm arguing against creating more excuses to arbitrarily hold up RFCs.  

More clearly, I expect IESG to make technical judgments about fitness of protocols.   But I don't think it's appropriate for IESG to be language police, except when following clearly established IETF consensus.   

- Comparing whether a technical specification in an RFC "SHOULD" or "MUST" be required in a standard to whether to continue using "master-slave" instead of "primary-secondary" does not make sense to me.

It's just a perhaps-familiar example of how people can be overzealous in interpreting rules.   I am not sure why people do it, but I've seen it happen many times.   Maybe some people over-interpret rules out of a desire to show how loyal/obedient they are, but often not a good thing.

Section 3.4.  Late Substitution of Words Considered Harmful
- I don't think there's a risk of confusing readers by doing things like seeking to change from "master-slave" to "primary-secondary".
I disagree, and again, that one example is not representative of all cases. 
- Late substitution can be avoided completely by documenting and continuing to document/discuss terminology that can be problematic.
"[A]voided completely" seems like an exaggeration, unless perhaps you have some processes in mind that I'm not aware of.   I do think that late substitution can be minimized if we realize it's a risk that needs to be managed. 
Section 4.2.  Complaints Preferred From Aggrieved Parties
- As others have stated, the entire IETF or at least a wide range of participants or even potential participants can be affected by an issue. It seems unfair to place the sole burden on them when we as a community can take the simple steps to change this like "master-slave" to "primary-secondary".

Again, the trivializing example.

But I wasn't intending to "place the sole burden" on anyone.   Rather I'm saying that when people take it upon themselves to be offended on behalf of other people, or to "fix" problems for other people of which they lack personal experience, they quite often get it wrong.   One of the ways they get it wrong is by being overzealous, and one of the reasons that people get it wrong is that the people arguing for such changes (often insistently) are trying to make themselves feel better (or more virtuous) rather than actually addressing a harm that they know firsthand through experience.

Another way to look at this is: while discouraging some words in favor of others might be good, discouraging or excluding more words is not inherently better, and we don't want to create conditions that enable people to exclude as many words as possible.

 As well, we need to consider the pipeline of future potential newcomers who may see the stubborn perpetuation of such terms as a clear signal that their participation is not welcome or desired, so how would they raise such an issue if they have been repelled from participation in the first place?

This argument keeps being made and I've seen no credible support for it.   We need to stop citing this as justification until there's clear evidence to support it.  I'm not saying we shouldn't change our language as there are clearly some cases for which we should.   But other potential changes have significant costs (both in the energy required and in the harm done to the readability of our specifications) and we need to not be making them for dubious reasons. 

Section 4.5.  Working Group Chairs May Limit Discussion of Language
- If a WG follows this advice then they seem to create the conditions you worry about in Section 3.4.  Late Substitution of Words Considered Harmful. IMO the sooner any problematic issues with a draft are raised, the better, regardless of whether those are technical or non-technical. I can tell you from my personal experience writing drafts that the sooner I hear of a concern the better and faster and more easily that I can deal with it.

I did say that issues could be raised at any time.    The point is to not have endless discussion about it.   I actually think that if issues are raised early, then there's a good chance that the people raising the issue can work things out with document authors/editors early.

I will admit that I'm not sure how best to handle such a discussion if it gets contentious and another proposal for how to do so might be better.   Consider this a placeholder and alternative suggestions are welcome.   Of course, it's not unusual for WG chairs to try to manage discussions that are blocking other progress, or to try to keep the same issues from being raised again and again in the absence of new information.

Section 4.7.  Blocking Based On Language Must be Based On IETF Consensus
- This seems at odds with your Section 4.1. On the one hand you seem to suggest the right approach is solely via the RFC Style Guide but on the other hand say nothing can be done absent an RFC.

I would draw a distinction between: (a) style advice for use by document authors/editors, including suggestions about which words to avoid and potential substitutes, versus (b) blocking document progress based on presence of certain words.   I'm fine with advice that allows authors/editors some discretion.   But I think IESG should not be able to block or significantly delay documents based on the presence of words, without IETF Consensus to back them up.

Section 4.9.  No Requirement To Revise Existing RFCs
- The IETF updates RFCs and BCPs all the time, even for limited replacement/update of specific terms. We just did a bunch of those when transitioning from the IAOC to the LLC for example, and it was fairly easy.

Revising many RFCs requires a Herculean effort for often-dubious benefit and IMO we do it far too often.   It's not a matter of just changing a few words.  Every erratum needs to be discussed and resolved.  Often there are long discussions about how to split particular hairs, how to reconcile minor incompatibilities between implementations of the old RFC, implementations of the new RFC, and existing practice that deviates from both.    It's typically necessary to not only sync the revised RFC with everything else that it references (some of which are moving targets).   And there's generally less community interest in doing due diligence on a revised RFC than there was for the original RFC - unless perhaps there are significant bugs to be fixed.   And of course there's the usual WG, IESG, and RFC Editor processing that is done with every RFC.  It hardly seems worth the trouble if there's not a good reason (like an interoperability failure) to change things.

So I maintain that gratuitous revision of RFCs is nearly always a Bad Idea.   We should find better ways to update RFCs than by revising them wholesale.

Keith


--------------5530D409EE366750BD0F1B10-- From nobody Thu Aug 27 12:35:45 2020 Return-Path: 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 11B023A127A for ; Thu, 27 Aug 2020 12:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 5iSbO80e6TJn for ; Thu, 27 Aug 2020 12:35:35 -0700 (PDT) Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4D93A1253 for ; Thu, 27 Aug 2020 12:35:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 8BEC8BA4CC39; Thu, 27 Aug 2020 14:35:27 -0500 (CDT) Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNWnv6oNWJ97; Thu, 27 Aug 2020 14:35:24 -0500 (CDT) Received: from [172.16.1.6] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 602BCBA4CC2A; Thu, 27 Aug 2020 14:35:24 -0500 (CDT) From: "Pete Resnick" To: "Niels ten Oever" Cc: gendispatch@ietf.org Date: Thu, 27 Aug 2020 14:35:23 -0500 X-Mailer: MailMate (1.13.1r5706) Message-ID: <507B4F04-E36E-4CE4-A0C6-904229410816@episteme.net> In-Reply-To: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> References: <6988d232-5fc5-c769-afea-a1d9c5d8f2fc@digitaldissidents.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Gendispatch] Grounding the exclusionary language discussion X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 19:35:44 -0000 Niels (and all), Due to other work constraints, I have not had a chance to go through the other 20-or-so messages that were sent today (and I have only had a chance to skim the new documents), and I probably will not have a chance to get to them until later tomorrow. However, just as I replied yesterday with regard to the comments on draft-knodel, I must repeat that focusing on the particulars in a draft (in this case, concerns that some of the claims lack citations) is not particularly helpful in evaluating the primary dispatch questions. Like draft-knodel, neither draft-moore or draft-gondwana have been adopted by any WG, and one or more of the three may or may not be used as a starting place to any WG we might propose. Commenting on the drafts themselves, as against identifying things that should or shouldn't be done if this work is to move forward, does not progress the discussion. pr On 27 Aug 2020, at 3:54, Niels ten Oever wrote: > Dear all, > > draft-moore-exclusionary-language and > draft-gondwana-effective-terminology both seem very concerned with the > potential for disruption of IETF processes if one were to provide > measures for the discussion of the issue of exclusionary language in > new I-Ds and RFCs. Both drafts also seem to find it very important > that if there is a (perceived) issue, this should be extensively > documented with evidence in the form of citations and numbers. > > However, both drafts don't provide any citations or quantification to > back up their own assertions and recommendations. I think it would be > very useful for a constructive discussion if the draft authors could > perhaps provide a bit more grounding to their arguments. > > This could for example be in scientific literature, or perhaps by > showing observed disruptions in similar or adjacent communities to the > IETF that have already instated such measures (such as Python, Django, > Linux Project, Bluetooth SIG, Drupal, Postgres, NIST, RedHat, etc). > > Best, > > Niels > > -- > Niels ten Oever > Researcher and PhD Candidate - DATACTIVE Research Group - University > of Amsterdam > Postdoctoral Scholar (abd) - Communications Department - Texas A&M > University > Research Fellow - Centre for Internet and Human Rights - European > University Viadrina > Associated Scholar - Centro de Tecnologia e Sociedade - Fundação > Getúlio Vargas > > W: https://nielstenoever.net > E: mail@nielstenoever.net > T: @nielstenoever > P/S/WA: +31629051853 > PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3 -- Pete Resnick https://www.episteme.net/ All connections to the world are tenuous at best From nobody Thu Aug 27 13:15:00 2020 Return-Path: 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 8AA033A1269 for ; Thu, 27 Aug 2020 13:14:58 -0700 (PDT) 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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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=comcast.com header.b=dmX2NK0B; dkim=pass (2048-bit key) header.d=comcast.com header.b=31dJfhs5; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=B0qrHwXR 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 zlyZPCb9HvI1 for ; Thu, 27 Aug 2020 13:14:57 -0700 (PDT) Received: from mx0b-00143702.pphosted.com (mx0b-00143702.pphosted.com [148.163.141.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BAA33A11FD for ; Thu, 27 Aug 2020 13:14:57 -0700 (PDT) Received: from pps.filterd (m0184889.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07RK3blo023749 for ; Thu, 27 Aug 2020 16:14:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=VO6ZkGSlMU5gwKaXCx6L6YVzuLoU8TdQhQYe0MtUhGo=; b=dmX2NK0BWiJkPrkkIfPfNcmiL8xWjHQiJXzo82IBAIdC5HIKoo7Wmj9aLPbZEYaQ/F3Z ZuVFTG8XhUaBgn9fTmkqy5uOrbC+sZpc3G6YGaeqit12kEzfBZx3bnbiWBzZqQPUJQju 7gzLTsOaDxMXf2PBxyP65hNShEVELI6LQ2TYvyTH2DWVKnu+P9nNpBejemCa6Vj4+XoQ XKcuXf4FRb3z7sVUTcJaieAPEk5MnbmiUmEPKbbeeoGI42jvUTQLpOKOOvje+zXu1df/ 6WMTRteUwKTaa2Vwn+P+YhSXYaPHKSKMX4/RKLjmQxhhRWNAFrLwwVS9qLJ7yulINcRv Mw== Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0b-00143702.pphosted.com with ESMTP id 3367fkuya9-93 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 27 Aug 2020 16:14:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1598559295; x=2462472895; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=VO6ZkGSlMU5gwKaXCx6L6YVzuLoU8TdQhQYe0MtUhGo=; b=31dJfhs5guCrq8JqegnHgS38J2x533A4Sv4dnNDeJ5a4/4gAZl6d2MYIHJv3adqc PAqd6jS0LKL7ttvptuIYlJxMMl9unnouUT+/8R1Izz6P6YfJajN2CtLnI8jDlmWb NqGb3PdzJDlIKHznSdNZXWQsAI8nNdgN6xaaj2JSnT6KNmk4eR5SFxCGg80Ofc4+ EIuLYiOA7K0EFkTW4nbbyKv6dGurTO3K/StppiGRf2zhDaHS98xbDOyMUupZsEjj zY83pBXTEZQdGq/a3vBPpHAWI1UlE2Tp51oWgw0prUTwYj0ATVFs+eFh3heKZ4sq 8rGoL8EoHTzN9E5eKn0byQ==; X-AuditID: 60729ed4-a49ff70000003048-54-5f48143fe0b5 Received: from COPDCEX13.cable.comcast.com (copdcmhoutvip.cable.comcast.com [96.114.156.147]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id D2.73.12360.F34184F5; Thu, 27 Aug 2020 14:14:55 -0600 (MDT) Received: from COPDCEX51.cable.comcast.com (147.191.125.150) by COPDCEX13.cable.comcast.com (147.191.124.144) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Aug 2020 14:14:54 -0600 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX51.cable.comcast.com (147.191.125.150) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 27 Aug 2020 14:14:54 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.173) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Aug 2020 16:14:33 -0400 Received: from MN2PR11MB4287.namprd11.prod.outlook.com (2603:10b6:208:189::17) by BL0PR11MB2945.namprd11.prod.outlook.com (2603:10b6:208:32::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3305.26; Thu, 27 Aug 2020 20:14:32 +0000 Received: from MN2PR11MB4287.namprd11.prod.outlook.com ([fe80::b951:e489:324b:cb3f]) by MN2PR11MB4287.namprd11.prod.outlook.com ([fe80::b951:e489:324b:cb3f%6]) with mapi id 15.20.3305.032; Thu, 27 Aug 2020 20:14:32 +0000 From: "Livingood, Jason" To: Bron Gondwana , "gendispatch@ietf.org" Thread-Topic: Comments on draft-gondwana-effective-terminology-01 Thread-Index: AQHWfK6tkNP+5apzV0em/iMt/28G6Q== Date: Thu, 27 Aug 2020 20:14:32 +0000 Message-ID: <5A52A107-2A65-4739-A1A9-AA24D654080F@cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: fastmailteam.com; dkim=none (message not signed) header.d=none;fastmailteam.com; dmarc=none action=none header.from=cable.comcast.com; x-originating-ip: [2601:87:4280:7190:b4ed:b077:c3d1:e0cc] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b2b9dd4c-3b91-4eb8-271b-08d84ac5cfa7 x-ms-traffictypediagnostic: BL0PR11MB2945: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pGUcIOaJksYcBjgZ49NFiqBwQ1qJL1+8j80xX34+2O5bSzJFuJlSf8vIHg7gKbrdIcVxKCllkKWwP5qQdHfCxGB+47RTGJ1EPZiEvTE2dGMTmtPWNHv4LIbviVUOUUeibF7XhKo9pXgGd1o9qn4YmvFAaNXGKpYBvJRwOy/5HwFVij3G4tf1pyVNAFRAkujvzE/IZToXFu4FqffnPbmFx3eLHwFEWwdluy8oRjfKKx8wKx2fEkf3AQgCp/UIRVRtUeuO49/7ZNadFaKhEDqwSbl6oDCzL9DlO3ZvAAj08Y2i9YxxbDksIjpornhvJB6JPTEvc/sUsF4RVtQs+GdzOA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4287.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(396003)(136003)(346002)(366004)(39860400002)(4743002)(2906002)(6486002)(71200400001)(8676002)(110136005)(2616005)(76116006)(64756008)(478600001)(33656002)(66556008)(66946007)(86362001)(6506007)(186003)(66476007)(6512007)(66446008)(316002)(5660300002)(8936002)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: 4/5hREVxJTvaXWt5bKUhMRavMpw1WdGIP8wirQWMEoIqQXkatEXrimNhyniDULo0flKpQkNr6sUyiUe44qI8c+mIcwOnm8RNz7YHeXAB42o8VBAQK4U5lP7Py9LhoWTrWT41cTbPG/A6xzm8HCCZSwWbU2EJZ9zv4hl7RSRz6yy02Jl5cretZsn4tJDkD0YOKH/B4LEABPauYv+Wp2xpTR6LahfBOgrJi4I2nqSZOMvET4M7uojQ3J/VosrReEIaXijaJFO736PddrS2sNFPlwVevkySQ62EshWqJHhp20XPkAbZDQLG7sBQ5Ke10mi+AKSbZRtYFj4tZ4wWr61dvenu3db6LY4/XsfFBcZLBKHBWrhfXg/t1Vb0KnPNhKMyE3OHNZHHjxbeg2YHDsS6yIW2aA9rWrv3fJNmIgj2wL+CXqVu5G9f0qvN1gi1n687m8Gkh7t+GQWJmoUDWtP83XXtckOoR22rTW5vL+24jbwAJE/zJ6Gli5tgnlxt6a3PfKAybD5EiJJNumUde9AUU7ePuFdtbeDu1W05KD64vHSMplOPHulgoNUIAxQI71ChIGzyFRfydExmwrkQkSEsuwI996ttLEKAU7RqQ7fFRAfYchlQ7dIiIgEwNDUl8l86isCSmN+Bp/QfXNj92cz4dY+6zorl2nAqo1kMTQkJ7AgQWavOfq9d1FOlPa9pShrJtD3us7B/MhWY92iytqaLcA== x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aTb1ZhyYdGvOFR+b/8NZXOesOweAxuvZK8ocMpL3/BWoPZ/4qME3L3TMgpLa00byyT1S++esPNdeOhFWqAKXowNvSW+Tu7FbL+FWWVbtLcCI0ryNwNTfRT6JqD3AukwZEbvawVIup3ywJRf1oBk0B1psKQSvDKIvM61bSRmiXDy22J9BxacLlQmapqHNyTADYvVkHiYCIQKk5buPwYgD15Ge4Y+L9Pi7tXkeu5NscbJ0AYMKNubRh9BuXFar7LBv3GHjnJP5eKP8xALSjQYtLUDGZcwi+ueToiwZHDRfCo2CG5szJ93dup/tKgcfwhHe2LSC69vkdhdcESw/yHoWcA== arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nqEF68JS8uVz1iKwllsMM5GIy/iUKKokud/i0MsUK7A=; b=T6I1q1NnFLv+9VItbkCqaO/wLJiFYm5zNHhB8snsbzum3x0IGuQ+Bh7n/Z8muvjETYO6ehwfrrG/MeOIVEPmNw7WSEgKBZxRRTXrLSCgdFr8gH/jSMivZZZ9fuPIvMxEofqSueg/xR1jPzV1GW8QLnlGXbL6GxGLfgXtDUG67JLfnLQZ6h8B0NUR/rMygyiaW42In0AWj6MEXi9oFm/DJZ7a4CBfeAlzAbcZNxFIDWAzC0FInzGAjX7pKdjC2MdEbcHr8RwL8hWcEdYENRnZvF97Tgf7rEO+TBDaaUp7Y/Cw65U1zvGstG4pSn2X4yxNFMjIlk7fv7CI7k+S9MiFVw== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cable.comcast.com; dmarc=pass action=none header.from=cable.comcast.com; dkim=pass header.d=cable.comcast.com; arc=none dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastcorp.onmicrosoft.com; s=selector1-comcastcorp-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nqEF68JS8uVz1iKwllsMM5GIy/iUKKokud/i0MsUK7A=; b=B0qrHwXRoQaFPdgtUAL6RgFKLFrbQ7G/BEL6MD5vD5gMwaGjwy3WU8zUX0lt3QNyQjMpl9L6kAOxPd7/EX7Ad1PWvFeyiC5RIFmVewiKHFzi9GGynfMND9PtCDMNRPBYsVrXtyfSpVztecTf4v9dKSR5PNFudmqkuG4ZPI0LmC0= x-ms-exchange-crosstenant-authas: Internal x-ms-exchange-crosstenant-authsource: MN2PR11MB4287.namprd11.prod.outlook.com x-ms-exchange-crosstenant-network-message-id: b2b9dd4c-3b91-4eb8-271b-08d84ac5cfa7 x-ms-exchange-crosstenant-originalarrivaltime: 27 Aug 2020 20:14:32.4067 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 906aefe9-76a7-4f65-b82d-5ec20775d5aa x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: NQ1fQgwPRZkHp3VLrWEcHP8X/xI8oAV5iFG3bNcnYRRHbj2oEADYAskyQSEZuad12asd5LVsLy+Ncya21k5of4vFi8ZIYfQtPU1E7+RRNzs= x-ms-exchange-transport-crosstenantheadersstamped: BL0PR11MB2945 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42JJKJozWddexCPe4GGHtsWfM/NZLeY3rGB1 YPK4/L2VyWPJkp9MAUxRXDYpqTmZZalF+nYJXBnvH79kLJgiXtHx+zpLA+MJsS5GTg4JAROJ zmu72bsYuTiEBA4zSTRP7WeEcA4xSjRPb2cFqRISuMMocX+rAUTiJKPE4iPnoKqWMElsnbSD HaLqEaPEqj8ZIDabgJnE3YVXmEFsEYFoibWHdrCA2MICthJH24+xQ8SdJGZc3MUEYetJNM6Y ALaNRUBVYvHpy2D1vAIuEr/m3warYRQQk/h+ag2YzSwgLnHryXwmiB8EJJbsOc8MYYtKvHz8 D2yOqIC+xOuOnVC9ixgl1hxXhaixlNi+fDk7hC0rcWl+NyOE7SvxYeZtFghbS+L4o+NQNdkS HXueskHY6hItH+exQthyEqt6H0LVy0g8uLGdDRQoEgK/mSR27pzDDuGcZpaYvPwNVMcfVonJ P4S6GDmAbBWJf4cqJzAaz0LyzyygDLOApsT6XfoQYQ+Jg5e6WCBsRYkp3Q/ZZ4GDRVDi5Mwn LAsYWVcx8lma6RkamugZmlroGRkabWIEp495V3YwXp7ucYhRgINRiYd31W/3eCHWxLLiylxg xHIwK4nwvj4KFOJNSaysSi3Kjy8qzUktPsQozcGiJM4bG3s2TkggPbEkNTs1tSC1CCbLxMEp 1cDoet6rh8d9t+ycj6cSz0zLfN3z06ntgsJmr7f9s2y4e99kR5y77nFz9gKNdfYtU/iCV3XL /vLc+3tSAqfxc4dXUQslyiydtDQ1+93u9LXrL86f7+ls37hq6utXTe4RJRVSmU6V7H+WrZrd aMrNHPOyRO+514yYksplhVyNNc95TRZczXA9KqjEUpyRaKjFXFScCADtNQDuGwMAAA== X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-27_12:2020-08-27, 2020-08-27 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: [Gendispatch] Comments on draft-gondwana-effective-terminology-01 X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 20:14:59 -0000 KHBlcnNvbmFsIHZpZXdzIC0gbm8gaGF0cykNCkkgcmVhZCBkcmFmdC1nb25kd2FuYS1lZmZlY3Rp dmUtdGVybWlub2xvZ3ktMDEgYW5kIGhlcmUgYXJlIHNvbWUgY29tbWVudHMgRldJVy4NCg0KU2Vj dGlvbiAyLjIuICBXb3JkcyBjYW4gZW5jb3VyYWdlIG9yIGRpc2NvdXJhZ2UgcGFydGljaXBhdGlv bg0KLSBJIGxpa2UgeW91ciBkaXNjdXNzaW9uIG9mIHRoZSB2YWx1ZSBvZiBkaXZlcnNpdHkgYW5k IGxvb2tpbmcgYXQgZW5jb3VyYWdpbmcgJiBkaXNjb3VyYWdpbmcgc2lnbmFscy4NCg0KU2VjdGlv biA0LjEuICBFbmdpbmVlcmluZyBjb25zaWRlcmF0aW9ucyB0YWtlIHByaW9yaXR5DQotIFlvdXIg cG9pbnRzIGFyZSBmYWlyIGVub3VnaCBJIHN1cHBvc2UsIHRvIG5vdCBiZSBzd2F5ZWQgYXMgZmFz aGlvbnMgY2hhbmdlIGFzIHlvdSBzYWlkLiBCdXQgSSB0aGluayBpdOKAmXMgYWxzbyBzb21ldGlt ZXMgdGhlIGNhc2UgdGhhdCBzb21ldGltZXMgY2hhbmdlIGNhbiBjb21lIHF1aWNrbHkuIFNvIGp1 c3QgYmVjYXVzZSBhIGNoYW5nZSBvZiBwZXJjZXB0aW9uIG9yIGludGVycHJldGF0aW9uIG9jY3Vy cyByZWNlbnRseSBkb2VzIG5vdCBtZWFuIHdlIHNob3VsZCBub3QgcGF5IGF0dGVudGlvbiBvciBy ZWFjdCB0byBpdCBhbmQgY29uc2lkZXIgaXQuDQoNClNlY3Rpb24gNC4zLiAgRGVjZW50cmFsaXNl ZCBjb250cm9sDQotIFlvdSB3cml0ZSB0aGF0ICJGaW5hbCB0ZXJtIGNob2ljZSBhbHdheXMgcmVz dHMgd2l0aCBkb2N1bWVudCBhdXRob3JzLiIgQnV0IGluIFdHIGRvY3VtZW50cyB0aGUgZG9jdW1l bnRzIHJlYWxseSBiZWNvbWUgdGhlIFdHJ3MsIHdlIGhhdmUgSUVTRyByZXZpZXcgdGhhdCBtYXkg c2VlayBjaGFuZ2VzIGFuZCBvZiBjb3Vyc2UgdGhlIFJGQyBFZGl0b3IgcHJvY2VzcyAobm90IHRv IG1lbnRpb24gdGhlIExhc3QgQ2FsbCBwcm9jZXNzKS4gU28gc3BlYWtpbmcgYXMgYW4gYXV0aG9y IG9mIGRvY3VtZW50cyBteXNlbGYsIGFmdGVyIHNvbWV0aGluZyBiZWNhbWUgYSBXRyBpdGVtIEkg aGFkIGxlc3MgY29udHJvbCBvdmVyIGNoYW5nZXMgYmVjYXVzZSBpdCB3YXMgYSByZWZsZWN0aW9u IG9mIHdoYXQgdGhlIFdHIGRlc2lyZWQgb3IgY2hhaXJzIGRpcmVjdGVkLCBldGMuDQoNCjYuICBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KLSBJIHN1c3BlY3QgdGhpcyBpcyB0aGUgc2VjdGlvbiB0 aGF0IHdpbGwgZWxpY2l0IHRoZSBtb3N0IGNvbW1lbnQgYW5kIHJlYWN0aW9uIGZyb20gcmV2aWV3 ZXJzLiBJIG1pZ2h0IHN1Z2dlc3QgdGhpcyBpcyBpbiBwYXJ0IGR1ZSB0byBwdXR0aW5nIHRoZXNl IGNvbmNlcm5zIGhlcmUgaW4gYSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIHJhdGhl ciB0aGFuIHNvbWUgcHJpb3Igc2VjdGlvbiBjYWxsZWQgIlBvdGVudGlhbCBmb3IgUHJvY2VzcyBD aGFsbGVuZ2VzIiBvciBzb21ldGhpbmcgbGlrZSB0aGF0LiBJIHJlY29tbWVuZCBtb3ZpbmcgaXQg b3V0IG9mIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIGJlY2F1c2UgdGhlIGNvbmNlcm5zIHlvdSBy YWlzZSBkb24ndCBhcHBlYXIgdG8gcGVydGFpbiB0byBzZWN1cml0eS4NCi0gSW4gdGVybXMgb2Yg dGhlIGNvbnRlbnQsIEkgYW0gdW5zdXJlIGl0IGlzIHBhcnRpY3VsYXJseSBjaGFsbGVuZ2luZyB0 byBlc3RhYmxpc2ggdGhhdCB0aGUgdXNlIG9mICdtYXN0ZXItc2xhdmUnIHJhaXNlcyBpc3N1ZXMg dGhhdCBjb3VsZCBub3QgZWFzaWx5IGJlIGF2b2lkZWQgYnkgdXNpbmcgJ3ByaW1hcnktc2Vjb25k YXJ5JyBmb3IgZXhhbXBsZS4gQW5kIGluIG15IGV4cGVyaWVuY2UgLSBwcm9iYWJseSBsaWtlIHlv dXJzIC0gSSd2ZSBzZWVuIHBsZW50eSBvZiBzcHVyaW91cyB0ZWNobmljYWwgY29tcGxhaW50cyBy YWlzZWQgaW4gdGhlIG5vcm1hbCBwcm9jZXNzIG9mIGRldmVsb3BpbmcgYSBkb2N1bWVudCBpbiBh IFdHLCBtb3N0IG9mIHdoaWNoIG9uIGFsbCBzaWRlcyBhcmUgb2Z0ZW4gaGFyZC9pbXBvc3NpYmxl IHRvIHByb3ZlIG9yIGV2YWx1YXRlLiBCdXQgdXN1YWxseSB0aGUgSUVURiBwcm9jZXNzLCBsZWZ0 IHRvIHdvcmsgYXMgZGVzaWduZWQsIHNvcnRzIHRoaXMgb3V0IHJlYXNvbmFibHkgd2VsbCwgbWVz c3kgdGhvdWdoIGl0IGFwcGVhciBpbiB0aGUgbW9tZW50Lg0KDQpUaGFua3MNCkphc29uDQoNCg0K From nobody Thu Aug 27 14:08:44 2020 Return-Path: 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 F42073A133D for ; Thu, 27 Aug 2020 14:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.851 X-Spam-Level: X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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=iecc.com header.b=NPxcjTPX; dkim=pass (2048-bit key) header.d=taugh.com header.b=Wp9Zs7RR 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 rTviiWA0nmbS for ; Thu, 27 Aug 2020 14:08:41 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 630063A1337 for ; Thu, 27 Aug 2020 14:08:41 -0700 (PDT) Received: (qmail 36954 invoked from network); 27 Aug 2020 21:08:38 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=9058.5f4820d6.k2008; bh=VyVMKNYwl5QfhZO/aAyKrkTiSUEZD1+5vr7YxlYhdd0=; b=NPxcjTPXbxFtXX9T9IXIHkWhmVvAt8jMPTMyp665nsfOM2Y+jcI3Je2LHsz3necV8+uMQipCmBh8cKgRf8aRIGSb7d1G00jyzfb0Dt4YFNaR9nfMEgELYqhZvE4sAjDTC/Z+7luMVDgF/DwX0mTXJ135ADn3xPsA+/hrVo3CW4t9USxIsoxObzxBrLYcUY2egRzL2Mq5f8ahHpu8nUe6xnkyJ3rjX4ND+C069MTaAucNlAtpWuJrlys2Qi2t89AIoD36i+ZoAT3Ksasxo+wF6FsbGS/lrC60LROV+C3YVX4vVerDX22oR1N+NWrW0To2Qj8QGaFDTSsJ0AgS0AfGBg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding; s=9058.5f4820d6.k2008; bh=VyVMKNYwl5QfhZO/aAyKrkTiSUEZD1+5vr7YxlYhdd0=; b=Wp9Zs7RRtIOm6cnkhX7hD/7PiwvzfK4u3RJUDU/P4jZYmLDwLXTnPOSNaCs7BnmFYm3z+MaOCeEkMKmtbJ2Rm0zFg3l4MO11MrOY6QuNdhQsdVyQe/yVx7R8QzvFh4kxof4FwWRX6ABOnk1leQhOMy+08rJSdlRJxwgXQzQtDjGgi0hNhj9x1V0DUEr+zYH065oevm4JNX1xZwBiW9jsq0Ybnl/OMgnMLYlKPWdPrjTN6oyGx6GK41uzZAXasoC7nnbGrYIEC4uUdVSOfIN55cjnBuKIZaJSgExGx6auUntJ2D5cXOeJGamRK+TZQ6qfxkm6a2BDLcOpJaBm6OsAhg== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 27 Aug 2020 21:08:38 -0000 Received: by ary.qy (Postfix, from userid 501) id D2F201F36A23; Thu, 27 Aug 2020 17:08:37 -0400 (EDT) Date: 27 Aug 2020 17:08:37 -0400 Message-Id: <20200827210837.D2F201F36A23@ary.qy> From: "John Levine" To: gendispatch@ietf.org Cc: moore@network-heretics.com In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Gendispatch] Fwd: New Version Notification for draft-moore-exclusionary-language-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 21:08:43 -0000 In article you write: >> As well, we need to consider the pipeline of future potential newcomers who may see the stubborn perpetuation of such terms as a clear >signal that their participation is not welcome or desired, so how would they raise such an issue if they have been repelled from participation >in the first place? > >This argument keeps being made and I've seen no credible support for >it.   We need to stop citing this as justification until there's clear >evidence to support it. ... I've seen plenty of examples of people who show up briefly and are repelled by the who-the-hell-are-you attitude of some of the mail replies. (I am surely not innocent here.) As a rather stale example, some years ago I posted a note to dnsop suggesting that with DNSSSEC, a DNS cache could synthesize negative answers to queries rather than asking the authoritative server, which would avoid some cache churn problems I anticipated with IPv6 DNSBLs. I promptly got a bunch of answers telling me that's not what DNSSEC is for and I was stupid even to suggest such a thing. Scroll forward a few years, that's now RFC 8198. Lucky for me my social skills are so poor that I didn't realize that being called stupid was an insult. This particular issue is considerably larger than whether we should say "slave" in our documents. R's, John From nobody Thu Aug 27 14:17:39 2020 Return-Path: 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 4CD203A135F; Thu, 27 Aug 2020 14:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 Rzat7q6ZY7ys; Thu, 27 Aug 2020 14:17:34 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50044.outbound.protection.outlook.com [40.107.5.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB7E93A135E; Thu, 27 Aug 2020 14:17:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E+04Ao1aL77NqpVuKEg8PWG0EXmk8z+I978tZiXk3fSiTI99y6BtT5Up36mwKVG1XFByafFUCciXpUN+FvnGEkd5yeAi6/z5xtWJ3yxN5Cnp/ESwcB/blit9uAZvcXNULjUNxOpm06NrbIRiGn0AOWUmu1rEk5olNyd/1f2DJgHtmDOpWs+ESFXZTdtjpfV7UlCdjy3mRKZ8XOO5Msq9DOMyv51GtCL2GqreXrJPKFtjV+ehiwSsL5j4vfxWBysjybhk8VVGehtQlhaXRSETitGQ2K0DaISqK6fsF7TUoUgf15cVmqwPbSw0CVDydbwKsoEJCQOdRcTtLNTDDQWdMg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aGbH6BxEw0m7hz0Og4TtmEqKv5EgYSMY+jfuvEYLdtI=; b=QPJ0edt0hs9xlZVWHvg0fBsFs1Rw9G6eqOxWVAJPpqDd3jB4B4j76VeVsfUhdV/VzlbiKzSVPYN6EjdPar5czD6ZXEqikCFwxaWDD8kSbydU8ltgndrUdd9W6jwztFVQraFksB4EbKTpbLj5yhrTE51FQd5Q3HhI8zl/Um7iorbcDzraWTWl9avsDviRLl5QeEwkVjyux7WDHGeCQHmaXxq2SyqY5MNh7QjXBV46e5So4wp/vqjGkXWA/y9meIaYFddfedtlXO5fvFkrgHU0u9Jb91c1tmrZ6CJczrQZC+7+KRTKYDWxic905dZykKttzpVZuVLy5d34eb3bPOY1rA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aGbH6BxEw0m7hz0Og4TtmEqKv5EgYSMY+jfuvEYLdtI=; b=ovpJ7yBKss8dGMgUiSLmWhWuTN5139cUZRKJUk7866guD3bBYdRmQoL640gXjaBxX7EW44JRTdbTSevfCXeZYOk2Vdm9Mw2Uc3ip5OaWabCet8DBx5CBS96ubgIcVlFACcMixdWcT0RcblE2q/L8s0OX8KWS210meGlUsYH2tqI= Received: from VI1PR07MB4477.eurprd07.prod.outlook.com (2603:10a6:803:74::33) by VI1PR07MB5999.eurprd07.prod.outlook.com (2603:10a6:803:cc::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.5; Thu, 27 Aug 2020 21:17:27 +0000 Received: from VI1PR07MB4477.eurprd07.prod.outlook.com ([fe80::cba:ac03:353c:2d1f]) by VI1PR07MB4477.eurprd07.prod.outlook.com ([fe80::cba:ac03:353c:2d1f%7]) with mapi id 15.20.3348.005; Thu, 27 Aug 2020 21:17:27 +0000 From: Francesca Palombini To: "gendispatch@ietf.org" CC: "gendispatch-chairs@ietf.org" Thread-Topic: [Gendispatch] General Area Dispatch (gendispatch) WG Virtual Meeting: 2020-09-01 Thread-Index: AQHWdj81mwTrgCdKOku/Fn0KzYV/ialMo/UA Date: Thu, 27 Aug 2020 21:17:27 +0000 Message-ID: References: <159785167583.11111.2959126579778884856@ietfa.amsl.com> In-Reply-To: <159785167583.11111.2959126579778884856@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081000 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ab91bbc8-4002-40b1-321b-08d84ace99ec x-ms-traffictypediagnostic: VI1PR07MB5999: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eIwWcnDwh+8X9jbd+q7CCvkKFfol0sqnO86zy0aiiRtzaSjZM/siF6F63U36Ly6LCd7GHL23Nr/wxblpB/0MB1+n/8wCGTpEPQTDzISBtjpbjwHuVwIA3jmf07pZecKPext/REpCJfXH7bQxOqR3kZKF0PVNoWOdKoKEKKmrvtNFMu7afvPvMS4tVM/Xzx54eFzchU0yaxwsO/Of+07K6xrgrDrIKtpwsSOoVEomlpiNiJwEivbvGpf3mEFBJt2BrFv/ye23KLL0sFQvTipx6K1OCEDc82eI2zVsgA4psqRF3Cq7azxhzeWQpon1i2eSHnA5loJbWCTjtGgawt4A4z016f0oEETAKMyFBrmwK2UAFCri9cYTXauBZ3pFN2BJ1xNFuZo+2VdnclF649xq+w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB4477.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(346002)(396003)(39860400002)(376002)(136003)(6512007)(71200400001)(86362001)(66446008)(76116006)(450100002)(66946007)(64756008)(5660300002)(16799955002)(66476007)(186003)(66556008)(66574015)(316002)(2616005)(6506007)(33656002)(2906002)(26005)(4326008)(6916009)(966005)(6486002)(91956017)(83380400001)(478600001)(8676002)(44832011)(83080400001)(36756003)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: toSbwv6i26zOyvJDv7q7DP6e6I+yEtRS7QqSNE8NMD3JA0LPlq3EsmAI9GzPpK8hjermZQivE+euMwDNfUftuzZPxKzY1Mman8MFtzl7FKK+gS7vnwOIcqC+zwJHyXltnBLvIhwAU3oAQ91LyQjWrJRV+l8dw2ZCNDrS2oz7EP1K+q5270Z6GawF+0CWR8auBYW6a3Uve2cDFrG3gxM/lx5VPVSWMaT0zDjz2NLNZVMzq68LDJTc9yjLPP8FTvD1prFNUc/YpX1np3Fq/3HJcTjEkS9AhfL/xmXR2H8o4pLaY3wJtIr1h77CIznFb9NErzlJSPBRNLtAr8zK/lxLFPRk81hF6Mh0keNwlM8OC2KP+rLUn4jjLQxUYAV9fr7+b/cQRWlL/1K2PzwK//UMOGCPjFzy8CzvCxskXepxHiuLz02RO0LuRZz694TiHbPY5r5qHGf4w8c+46iV+JBNxXpBY1RcBDfCfO4SWe4JDUl6Pyv5iORgYJPQk0kvN5F6SSkk/gxeUDZmQNRNu5cr30uvrnbXsxW9RpLivU7i1o/rm+1nbH7vrSSuPdquzbSSXd9yoE3OOJtNNKhtpxQ47RdRrjMQqj60y/b56c8u06PjMLx37byWMmT2LEjPDQwXWbdLsORyDHedYPfPjA53BA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <7DE6D3717EB67F448FF2CB7243A54D17@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB4477.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ab91bbc8-4002-40b1-321b-08d84ace99ec X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2020 21:17:27.7627 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: q+MzMlSn75mjzsn3u9QSCTXB+YqPpOD94lCZvyKDzb0pbjIHFwMiXdw8+N2IeL2qfvX2W3Tf1gOeR3ljfOhjYBmIy1sWjjefaSlTmRE2pKLrXfWtac7SJt1dQ7KI6mxE X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5999 Archived-At: Subject: Re: [Gendispatch] General Area Dispatch (gendispatch) WG Virtual Meeting: 2020-09-01 X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 21:17:36 -0000 SGkgYWxsLA0KDQpJbiBwcmVwYXJhdGlvbiBmb3IgbmV4dCB3ZWVrJ3MgbWVldGluZywgUGV0ZSBh bmQgSSBoYXZlIGRyYWZ0ZWQgYW4gYWdlbmRhIChwYXN0ZWQgYmVsb3cpLCB3aGljaCBhbHNvIGlu Y2x1ZGVzIGEgc3VtbWFyeSBvZiB0aGUgZGlzY3Vzc2lvbiBzbyBmYXIgKG5vdCBpbmNsdWRpbmcg dGhlIGxhc3QgY291cGxlIG9mIGRheXMpIGFuZCBhIHN0YXJ0aW5nIHBvaW50IGZvciB0aGUgZGlz Y3Vzc2lvbiBhdCB0aGUgaW50ZXJpbS4gUGxlYXNlIHRha2UgYSBsb29rIGJlZm9yZSB0aGUgaW50 ZXJpbS4NCg0KVGFsayB0byB5b3UgYWxsIHNvb24sDQpGcmFuY2VzY2ENCg0KLS0tLS0NCg0KaW50 ZXJpbS0yMDIwLWdlbmRpc3BhdGNoLTAxDQoNCkdlbmRpc3BhdGNoIEludGVyaW0gDQpUdWVzZGF5 IDIwMjAtMDktMDEgMjA6MDAgVVRDDQpDaGFpcnM6IEZyYW5jZXNjYSBQYWxvbWJpbmksIFBldGUg UmVzbmljaw0KDQpXZWJleDogaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9 bWMyYWE4NjkzZWRlYWIxZmFmMTdlOTI5NTRjNDRmMzE2DQoNCk1pbnV0ZXMgJiBCbHVlc2hlZXQ6 IGh0dHBzOi8vY29kaW1kLmlldGYub3JnL25vdGVzLWlldGYtaW50ZXJpbS0yMDIwLWdlbmRpc3Bh dGNoLTAzLWdlbmRpc3BhdGNoDQoNCi0gQ2hhaXIgaW50cm8gKDUgbWludXRlcykNCgkqIFJlbWlu ZGVyOiB3ZSBhcmUgbG9va2luZyB0byBhbnN3ZXIgdGhlIGRpc3BhdGNoIHF1ZXN0aW9uLg0KICAJ CS0gVGhlIGRpc2N1c3Npb24gb24gY29udGVudCBzaG91bGQgYmUga2VwdCBvbiB0aGUgbGluZXMg b2YgaWYvd2hhdCB0aGUgSUVURiBzaG91bGQgd29yayBvbiwgYXMgdGhhdCBpbXBhY3RzIHRoZSAi d2hlcmUiLg0KCSAgCS0gV2UgYXJlIG5vdCB0cnlpbmcgdG8gc29sdmUgdGhlIHByb2JsZW0sIHdl IGFyZSB0cnlpbmcgdG8gZmlndXJlIG91dCB3aGF0IHBhcnQgb2YgdGhpcyBhcmVhIHRoZSBJRVRG IHNob3VsZCB3b3JrIG9uLg0KICAJCS0gSGVscGZ1bDogd2hhdCB3b3VsZCBiZSBhIHNhdGlzZmFj dG9yeSBvdXRwdXQgdG8gdGhlIGRpc2N1c3Npb24gKEJDUCwgaW5mb3JtYXRpb25hbCwNCiAgCQl1 cGRhdGVzIHRvIHRoZSBSRkMgU3R5bGUgR3VpZGUsIGNoYW5nZXMgdG8gdGhlIGlkbml0cyB0b29s LCBHZW4tQXJ0IHJldmlldyBndWlkZWxpbmVzLCBzb21ldGhpbmcgc2ltaWxhciB0byBXM0MgbWFu dWFsIG9mIHN0eWxlOiBodHRwczovL3czYy5naXRodWIuaW8vbWFudWFsLW9mLXN0eWxlLyNpbmNs dXNpdmUsIC4uLikNCiAgCQktIHdlIGhhdmUgZ29uZSB0aHJvdWdoIG1pbnV0ZXMgWzFdLCBqYWJi ZXIgbG9ncyBbMl0sIGFuZCBnZW5kaXNwYXRjaCBtYWlsaW5nIGxpc3QgZGlzY3Vzc2lvbiAoaW5j bHVkaW5nIHRoZSB0aHJlYWQgc3RhcnRpbmcgYXQgWzNdKSBhbmQgdHJpZWQgdG8gc3VtbWFyaXpl IHRoZSBkaXNjdXNzaW9uIGhlcmUgKHNlZSBiZWxvdykNCg0KLSBUZXJtaW5vbG9neSBwcm9wb3Nh bHM6DQoJKiBUZXJtaW5vbG9neSwgUG93ZXIsIGFuZCBJbmNsdXNpdmUgTGFuZ3VhZ2UgaW4gSW50 ZXJuZXQtRHJhZnRzIGFuZCBSRkNzDQoJaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWtub2RlbC10ZXJtaW5vbG9neS0wNCANCgkqIEVmZmVjdGl2ZSBUZXJtaW5vbG9neSBpbiBJRVRG IGRyYWZ0cw0KCWh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1nb25kd2FuYS1lZmZl Y3RpdmUtdGVybWlub2xvZ3ktMDEgDQoJKiBBdm9pZGluZyBFeGNsdXNpb25hcnkgTGFuZ3VhZ2Ug aW4gUkZDcw0KCWh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tb29yZS1leGNsdXNp b25hcnktbGFuZ3VhZ2UtMDAgDQogIA0KCSogU3VtbWFyeSBmcm9tIElFVEYxMDg6DQoJICAJLSB0 aGVyZSBpcyBkaWZmZXJlbmNlIG9mIG9waW5pb24gYmV0d2VlbiB0aGUgcHJvYmxlbSB0aGlzIGRy YWZ0IHdhbnRzIHRvIHNvbHZlIGFuZCB0aGUgZHJhZnQgaXRzZWxmICh3ZSBhcmUgdHJ5aW5nIHRv IGRpc3BhdGNoIHRoZSBwcm9ibGVtIGFzIHdlbGwgYXMgdGhlIGRyYWZ0KQ0KCSAgCS0gdGhlcmUg d2VyZSBkaWZmZXJlbnQgb3BpbmlvbnMgYmV0d2VlbiB0aGUgcHJvYmxlbSB0aGlzIGRyYWZ0IHdh bnRzIHRvIHNvbHZlIGFuZCB0aGUgZHJhZnQgaXRzZWxmICh3ZSBhcmUgdHJ5aW5nIHRvIGRpc3Bh dGNoIHRoZSBwcm9ibGVtIGFzIHdlbGwgYXMgdGhlIGRyYWZ0KQ0KCSAgCS0gdGhlcmUgd2FzIHN1 cHBvcnQgb24gdGhlIHN0YXRlbWVudCB0aGF0IElFVEYgc2hvdWxkIGFkZHJlc3MgdGhlIHByb2Js ZW0gdGhpcyBkcmFmdCBicmluZ3MgZm9yd2FyZA0KCSAgCS0gc2Vuc2Ugb2YgdGhlIHJvb20gdGhh dCBkcmFmdC1rbm9kZWwtdGVybWlub2xvZ3kgaXMgbm90IGEgZ29vZCBzdGFydGluZyBwb2ludA0K CSAgCS0gdGhlcmUgbmVlZHMgdG8gYmUgbW9yZSBkaXNjdXNzaW9uIG9uIGNvbnRlbnQgdG8gdW5k ZXJzdGFuZCB3aGF0IHdvdWxkIGJlIGEgZ29vZCBzdGFydGluZyBwb2ludA0KCSAgCS0gdGhlcmUg ZXhpc3Qgc2V2ZXJhbCBvcHRpb25zIGZvciB0aGUgZGlzY3Vzc2lvbiBvbiBjb250ZW50IHRvIHRh a2UgcGxhY2UuIFRoZSBzZW5zZSBvZiB0aGUgcm9vbSB3YXMgdGhhdCBkaXNjdXNzaW9uIG9uIGll dGZAaWV0ZiBtYWlsaW5nIGxpc3Qgd2FzIG5vdCBwcm9kdWN0aXZlLiBPcHRpb25zOg0KCQkgIAkq IENvbnNlbnN1cyBvbiBuZWVkIGZvciBhIGRlZGljYXRlZCBtYWlsaW5nIGxpc3QgKyB2aXJ0dWFs IG1lZXRpbmdzICgvaW50ZXJpbXMpIChub3RlOiBzb21lIGNvbnRlbnQgZGlzY3Vzc2lvbiB3YXMg c3RhcnRlZCBvbiBnZW5kaXNwYXRjaCwgaW4gdGhlIG1lYW50aW1lKQ0KCQkgIAkqIEFEIHNwb25z b3JlZCAod2hpY2ggd291bGQgcmVtb3ZlIHRoZSBvdmVyaGVhZCBvZiBjcmVhdGluZyBhIG5ldyBX RykNCgkJICAJCS0gd2hlcmUgdG8gaGF2ZSB0aGUgZjJmIGRpc2N1c3Npb24/DQoJCSAgCSogZGlz cGF0Y2ggdG8gYSBuZXcgV0csIHdoaWNoIHdvdWxkIGdpdmUgYSBjbGVhcmVyIHBsYWNlIHRvIGJ1 aWxkIGNvbnNlbnN1cyBhbmQgaGF2ZSBkaXNjdXNzaW9uDQoJCSAgCSogZGlzcGF0Y2ggdG8gQk9G IGZvciBkaXNjdXNzaW9uDQoJCSAgCSogSUFCIHByb2dyYW0NCg0KCSogQnJpYW4gQ2FycGVudGVy IHN1bW1hcnkgb2Ygb3V0cHV0cyBbNF0gKG5vdCBjb21wbGV0ZSwgZG9lcyBub3QgbGlzdCBJQUIg cHJvZ3JhbSwgQk9GLCAuLi4pOg0KCQkxLiBSZWNvbW1lbmQgdGhhdCBpdCBiZSBkcm9wcGVkIGZy b20gSUVURiBjb25zaWRlcmF0aW9uLi4uDQoJCTEuMS4gLi4uYW5kIHJlZmVycmVkIHRvIHRoZSBJ bmRlcGVuZGVudCBzdHJlYW0NCgkJMS4yLiAuLi5hbmQgcmVmZXJyZWQgdG8gdGhlIFJGQyBFZGl0 b3INCgkJMS4zLiAuLi5hbmQgZm9yZ290dGVuDQoJCTIuIFJlY29tbWVuZCB0aGF0IGEgV0cgb24g dGhpcyB0b3BpYyBiZSBmb3JtZWQuLi4NCgkJMi4xLiAuLi5hbmQgYXNrZWQgdG8gdXNlIHRoZSBk cmFmdCBhcyBhIHN0YXJ0aW5nIHBvaW50DQoJCTIuMS4gLi4uYW5kIGFza2VkIHRvIHN0YXJ0IGEg Y29tcGxldGVseSBuZXcgZHJhZnQNCgkJMy4gUmVjb21tZW5kIHRoYXQgYSBzcG9uc29yaW5nIEFE IGJlIGZvdW5kLi4uDQoJCTMuMS4gLi4uYW5kIHRoYXQgdGhlIGRyYWZ0IGJlIHVzZWQgYXMgYSBz dGFydGluZyBwb2ludA0KCQkzLjIuIC4uLmFuZCB0aGF0IHRoZSBBRCBzb2xpY2l0cyBhIGNvbXBs ZXRlbHkgbmV3IGRyYWZ0DQoJCTQuIFJlY29tbWVuZCB0aGF0IHRoZSBpc3N1ZSBiZSBoYW5kbGVk IHNvbGVseSBieSB0aGUgSUVTRw0KCQk1LiBSZWNvbW1lbmQgdGhhdCB0aGUgaXNzdWUgYmUgaGFu ZGxlZCBzb2xlbHkgYnkgdGhlIFJGQyBFZGl0b3INCg0KDQpbMV0gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvcHJvY2VlZGluZ3MvMTA4L21pbnV0ZXMvbWludXRlcy0xMDgtZ2VuZGlzcGF0Y2gtMDEgDQpb Ml0gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvamFiYmVyL2xvZ3MvZ2VuZGlzcGF0Y2gvMjAyMC0wNy0z MC5odG1sIA0KWzNdIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvZ2VuZGlz cGF0Y2gvenNJVmVmRFFMektRMldGNEt1S3lQbTFfbUZJLyANCls0XSBodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL2dlbmRpc3BhdGNoL25lN0ZRRUJRZUhtYnpfN3k2MndwSnVB UjlOQS8gDQoNCu+7v09uIDE5LzA4LzIwMjAsIDE3OjQxLCAiR2VuZGlzcGF0Y2ggb24gYmVoYWxm IG9mIElFU0cgU2VjcmV0YXJ5IiA8Z2VuZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgaWVzZy1zZWNyZXRhcnlAaWV0Zi5vcmc+IHdyb3RlOg0KDQogICAgVGhlIEdlbmVyYWwg QXJlYSBEaXNwYXRjaCAoZ2VuZGlzcGF0Y2gpIFdHIHdpbGwgaG9sZA0KICAgIGEgdmlydHVhbCBp bnRlcmltIG1lZXRpbmcgb24gMjAyMC0wOS0wMSBmcm9tIDIwOjAwIHRvIDIyOjAwIFVUQy4NCg0K ICAgIEFnZW5kYToNCiAgICBEaXNjdXNzaW9uIG9mIGRvY3VtZW50IHRlcm1pbm9sb2d5LiBEZXRh aWxlZCBhZ2VuZGEgd2lsbCBiZSBwcm92aWRlZCBzb29uLg0KDQogICAgSW5mb3JtYXRpb24gYWJv dXQgcmVtb3RlIHBhcnRpY2lwYXRpb246DQogICAgaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRm L2oucGhwP01USUQ9bWMyYWE4NjkzZWRlYWIxZmFmMTdlOTI5NTRjNDRmMzE2DQoNCiAgICAtLSAN CiAgICBHZW5kaXNwYXRjaCBtYWlsaW5nIGxpc3QNCiAgICBHZW5kaXNwYXRjaEBpZXRmLm9yZw0K ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ2VuZGlzcGF0Y2gNCg0K From nobody Thu Aug 27 14:29:53 2020 Return-Path: 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 7C5863A1384 for ; Thu, 27 Aug 2020 14:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.843 X-Spam-Level: X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.948, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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=messagingengine.com 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 WbEZT1gQnXxe for ; Thu, 27 Aug 2020 14:29:51 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76CEC3A1386 for ; Thu, 27 Aug 2020 14:29:51 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 7DC2210DD; Thu, 27 Aug 2020 17:29:50 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 27 Aug 2020 17:29:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=NvaRHFB2J692n8iu4w6goyxpCA72h6f6fV8PeblXC GY=; b=PdG1OU0wUIbdi4orJJu02hzPmTFzRN/tdvunbwC+KtUP3qOK/wZ8zwDld Aw7DL756fdMAVgVNz2P+wQOYPuYxjLyfAihxa20YaQGcvIStf/KzgooTuZrK/vY2 GfAndFmUhN0rtJ/9hxN5grHqaxAluGzuSpEZHY2Epw9Swmd1iWMzyBn5v4cpb4V/ ME0EGQ7SZ2bvwN0QD7l8M9wVhu4KoHOeQuVKp1eCZuBADyWKdVnvVgd5uXQPIVzR kNfYGpyblWcPXpW+V+bfNiGlms731EAb6gfuazaX82noCNfp3RtcVEHczI3Jbfww S/0luF0oBDr5v8QuJUNWpPYXJabNQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddviecutefuodetggdotefrodftvfcurf hrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjug hrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpefmvghithhhucfo ohhorhgvuceomhhoohhrvgesnhgvthifohhrkhdqhhgvrhgvthhitghsrdgtohhmqeenuc ggtffrrghtthgvrhhnpeehhfeutdehfefgfefghfekhefguefgieduueegjeekfeelleeu ieffteefueduueenucfkphepuddtkedrvddvuddrudektddrudehnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhoohhrvgesnhgvthifohhr khdqhhgvrhgvthhitghsrdgtohhm X-ME-Proxy: Received: from [192.168.1.85] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 5D4FC328005A; Thu, 27 Aug 2020 17:29:49 -0400 (EDT) To: John Levine , gendispatch@ietf.org References: <20200827210837.D2F201F36A23@ary.qy> From: Keith Moore Message-ID: Date: Thu, 27 Aug 2020 17:29:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200827210837.D2F201F36A23@ary.qy> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Gendispatch] Fwd: New Version Notification for draft-moore-exclusionary-language-00.txt X-BeenThere: gendispatch@ietf.org 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: Thu, 27 Aug 2020 21:29:53 -0000 On 8/27/20 5:08 PM, John Levine wrote: > I've seen plenty of examples of people who show up briefly and are > repelled by the who-the-hell-are-you attitude of some of the mail > replies. So have I, but I think the intersection between that problem, and the use of words currently under discussion, is small. (And yes, we should do better.   But I also see plenty of examples in which people who really don't have the background are treated with courtesy and patience, and sometimes those folks end up being valuable contributors.) > This particular issue is considerably larger than whether we should > say "slave" in our documents. Yes, I expect so. Keith From nobody Fri Aug 28 06:23:19 2020 Return-Path: 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 A84E63A0BE3 for ; Fri, 28 Aug 2020 06:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=akamai.com 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 aWnW8Eu3tUOd for ; Fri, 28 Aug 2020 06:23:16 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D1D3A0BDF for ; Fri, 28 Aug 2020 06:23:16 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 07SDMvTI015854; Fri, 28 Aug 2020 14:23:15 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=ucHwNzbhRKejXzDmz79SA7RfvQZtrF4AVngCPt7PN+g=; b=YkjEE3Du3i29dM7PQr7K7s9PkvuUTGeBf6FdppK6Wo3gpUpAwmarTtHEzM/e0asEzDdP riEmtNNqeFttPRFs3zI/PA13sGqVWrSuiPYUfGjTxNN2rCzOCouWTlYLLCaFBRqFruSQ HdQgcv/ryg5T5OvfkBlrap2UdpcF+QPufbewP88aHKOccYDjDVreH8unmr43Yi/pcnoD 1oNuF46Jm4FYwlL5iNdgtBelE6SCSZiQ4kYCAAXI7DoVbE6K0PdhDZrzVxDEhE5LAPFv EKQJDC0ObyxCBv+oLUpaFtB86InzKb1E3jIdyvPr9sGvMdFiJ79hLPansxvL83Wd0frK Yw== Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 332u1ad7xm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Aug 2020 14:23:15 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 07SD5wo1025665; Fri, 28 Aug 2020 09:23:14 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint4.akamai.com with ESMTP id 332xpxy1a7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 28 Aug 2020 09:23:14 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 28 Aug 2020 09:23:13 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1497.006; Fri, 28 Aug 2020 09:23:13 -0400 From: "Salz, Rich" To: John Levine , "gendispatch@ietf.org" CC: "moore@network-heretics.com" Thread-Topic: [Gendispatch] Fwd: New Version Notification for draft-moore-exclusionary-language-00.txt Thread-Index: AQHWfAjQr5kKevN6iEWGjfP/dZcIKqlMeAiAgAAlFICAABpWgIAAzT4A Date: Fri, 28 Aug 2020 13:23:13 +0000 Message-ID: <3CD5AB63-47C2-478C-A835-7897E3AF21BA@akamai.com> References: <20200827210837.D2F201F36A23@ary.qy> In-Reply-To: <20200827210837.D2F201F36A23@ary.qy> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.40.20081201 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-28_08:2020-08-28, 2020-08-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 mlxscore=0 adultscore=0 bulkscore=0 mlxlogscore=880 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008280098 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-08-28_08:2020-08-28, 2020-08-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 suspectscore=0 adultscore=0 priorityscore=1501 impostorscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxlogscore=821 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008280102 Archived-At: Subject: Re: [Gendispatch] Fwd: New Version Notification for draft-moore-exclusionary-language-00.txt X-BeenThere: gendispatch@ietf.org 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: Fri, 28 Aug 2020 13:23:18 -0000 PiAgICBJJ3ZlIHNlZW4gcGxlbnR5IG9mIGV4YW1wbGVzIG9mIHBlb3BsZSB3aG8gc2hvdyB1cCBi cmllZmx5IGFuZCBhcmUNCiAgICByZXBlbGxlZCBieSB0aGUgd2hvLXRoZS1oZWxsLWFyZS15b3Ug YXR0aXR1ZGUgb2Ygc29tZSBvZiB0aGUgbWFpbA0KICAgIHJlcGxpZXMuIChJIGFtIHN1cmVseSBu b3QgaW5ub2NlbnQgaGVyZS4pDQoNCkl0J3MgdG91Z2gsIGJhbGFuY2luZyAiYmUgaW5mb3JtZWQg b2YgdGhlIGhpc3RvcnkiIHdpdGggIndlbGNvbWluZyBuZXcgY29udHJpYnV0aW9ucyIgYW5kIHdl IHNob3VsZCBiZSBhYmxlIHRvIGRvIGEgYmV0dGVyIGpvYi4gIChQaXR5IHRoZSBwb29yIG5vb2Ig d2hvIHN0ZXBzIGludG8gRE5TIGZvciBleGFtcGxlLikgIEJ1dCB0aGF0J3MgcHJvYmFibHkgb2Zm LXRvcGljIGZvciB0aGlzIGxpc3QuDQogDQoNCg==