Re: IESG Statement On Oppressive or Exclusionary Language

Victor Kuarsingh <victor@jvknet.com> Fri, 24 July 2020 17:09 UTC

Return-Path: <victor@jvknet.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAC33A1008 for <ietf@ietfa.amsl.com>; Fri, 24 Jul 2020 10:09:03 -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=jvknet-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 14uHu7CmKBSi for <ietf@ietfa.amsl.com>; Fri, 24 Jul 2020 10:09:01 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 7F90A3A1009 for <ietf@ietf.org>; Fri, 24 Jul 2020 10:08:57 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id a14so8967866wra.5 for <ietf@ietf.org>; Fri, 24 Jul 2020 10:08:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jvknet-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LKBlzEHRnoRiRglj1NmJ/rmeqn01FmT75JANRAfScsM=; b=x4AO3d9KrGYFOb5xV0CmUPMTfvqK/lsuPu8uGvk3t20xOE6mUWP+xWOBIFDTBIp8yC satSfbRVUMFns21m3qSMlcD1VGMXXclRPns7q+Sl64YFIHyhx7WS1wJ7uXf67HHCnfMD 8JeXuryNxiqmoQqnkpnLTldXBTMOQXxWpNtXTH5tSkYl8ssL8iBkB9Zetmb7fWpaEQLu GScufVOPYNbrRXQQMEVuA8abky4rytSkkza1tJWmdKBz71iM+OErTAl9KQEx5/zhqURd uq8QMQKTgeBc4sIjkQAU3EDJi0BvrlsaWSjRP6X4RAHtvDX5J1J93r/UCwgUX8+Krsvj Z5Iw==
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=LKBlzEHRnoRiRglj1NmJ/rmeqn01FmT75JANRAfScsM=; b=CrXzXmXn4M754d/5ZSeRjwgXDeh1kN32n/ZMxphMW74TRQOJPH+AKevdqwXO0BOviE O6v86zpBAkQ9HKs1W3a14FFx2hNch0HXBpBMNoWDqSpSlHF2a+WUVQ+3tjKi0WJuE81K zNOchYMoBlIAKw6588B22g1hgKSK1Pg5oR3R5b5v8eOpaktDqmC1ufEJN0Cw4UZAjOGx Ru5OJR5s023Lz/fy3SQJzBxmDx5dTHrmQkoIhRZoDQrzqA4mEnhTClbrbgWLqushvnPY ZNeZ49PAfnom37nBJEc71x3lRa6Zz/BUVFQDIMseHwrm2Cabadp/5c2Rww6eG50yYKX6 fq9g==
X-Gm-Message-State: AOAM531F2KXjuTPV6rXX0yp7wknEK+vgGOYMhREVttL4ugmV3q+LRCXu lSrCnqxCiO7OEpIx1R1oQw37tnJFZTfo+A0q240WN62rlju2cBG+
X-Google-Smtp-Source: ABdhPJxhF7LldZpdZLl17ExtJpTy2zs5X41j92SAUb7MkyfVYiGhLhcvvhtC+A19vWKLzL5do7MJI30APhIRXT/NVZo=
X-Received: by 2002:a5d:46ce:: with SMTP id g14mr10019129wrs.188.1595610535886; Fri, 24 Jul 2020 10:08:55 -0700 (PDT)
MIME-Version: 1.0
References: <159552214576.23902.6025318815034036362@ietfa.amsl.com> <E90735A0-90B4-4855-BCE1-3F1A70B405F8@eggert.org> <94729FE7-4820-4927-A4A8-AD004A8BB65B@cable.comcast.com>
In-Reply-To: <94729FE7-4820-4927-A4A8-AD004A8BB65B@cable.comcast.com>
From: Victor Kuarsingh <victor@jvknet.com>
Date: Fri, 24 Jul 2020 13:08:44 -0400
Message-ID: <CAJc3aaPzp-oJdZeEW3VZNFQbjH2_97u3TbyseLQETnJZJfc-Pw@mail.gmail.com>
Subject: Re: IESG Statement On Oppressive or Exclusionary Language
To: "Livingood, Jason" <Jason_Livingood@comcast.com>
Cc: Lars Eggert <lars@eggert.org>, IETF list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000031178405ab3307dd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/A6xQN1cppytM3RUXHvFaS_XA3wc>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jul 2020 17:09:03 -0000

On Fri, Jul 24, 2020 at 12:33 PM Livingood, Jason <
Jason_Livingood@comcast.com> wrote:

> +1
>
> On 7/24/20, 8:33 AM, "ietf on behalf of Lars Eggert" <
> ietf-bounces@ietf.org on behalf of lars@eggert.org> wrote:
>
>     Hi,
>
>     I've been reading this thread, and don't understand how this IESG
> statement is controversial.
>
>     Many of us learned in recent years that some terminology and language
> that's been used in the past alienates or is otherwise objectionable to a
> part of our community. Alternative terms readily exist, sometimes even
> offering a more precise meaning. How is it not the right thing to simply
> start using these alternative terms when we can?
>
>     Sure, an occasional change in terminology is only a small step. But
> it's still moving us in the right direction, and costs us practically
> nothing.
>


This may be true.  Have we assessed the full impact of doing so, and what
issues it may raise to the contrary?    Some of the challenges I see
(forgive me if I have missed substantive discussion points on this matter
to date) include:

- Language evolves (especially english), so the meaning of words are not
constant
- Often terms (or words) have more than one meaning, and how do we provide
consistency in approach to terms/words we should avoid?
- in Reading "draft-knodel-terminology-03.pdf", I see a number of good
points noted, but I did not see much in the way of describing the counter
argument (or at least impacts of such)
- The IETFs work often intersects work from other organizations/communities
outside of those listed in the draft above (e.g. . Have we assessed the
impacts of potentially changing things such that it is not not consistent
with works that are produced outside the IETF but also intersect with the
IETFs?
- In the draft noted above, I would argue that some of the suggested terms
may not actually be more technically accurate (it depends).   Often the
words/terms most meaningful are those recognized by the audience in
addition to the author (where the audience may be a very large extended
group)
- if alternative terms can be used in some instances, but perhaps less
appropriate in others (based on technical accuracy or consistency), does
the divergence of terms across intersecting technologies,
implementations or documents matter?

I am certainly not advocating to not go down this path, but would think
understanding the impacts of doing so are important.

regards,

Victor K


>
>     Lars
>
>