Re: IESG Statement On Oppressive or Exclusionary Language

Nadim Kobeissi <nadim@symbolic.software> Sun, 09 August 2020 09:06 UTC

Return-Path: <nadim@symbolic.software>
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 9FA653A0BE7 for <ietf@ietfa.amsl.com>; Sun, 9 Aug 2020 02:06:05 -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 (1024-bit key) header.d=symbolic.software
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 DLDOOorq-TF2 for <ietf@ietfa.amsl.com>; Sun, 9 Aug 2020 02:06:01 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 5B6B43A0BE9 for <ietf@ietf.org>; Sun, 9 Aug 2020 02:06:01 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id r4so5418655wrx.9 for <ietf@ietf.org>; Sun, 09 Aug 2020 02:06:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symbolic.software; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=in4+5/UCPFI0ZufQ3PoBBUEaqiGYGjAFaeRuEY/bWEA=; b=YdB7gkuazOyadlYrsp2a8T6bWc3b29foygsnzl3PwTFJp551iUAGA2FF3kdGH90LDX kGONpDpNJhuyZDZDoIHTE0IK0+rkVQLwJ7K1iBxXMCM747lvELpypB3df0+E5BSyHCr5 7U01QHjWLJVKECF+CG31DCXpcqPxGdL8KWn4Q=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=in4+5/UCPFI0ZufQ3PoBBUEaqiGYGjAFaeRuEY/bWEA=; b=M2zGxGlvgPeVqwTSsb/MZmhv/pFjlwpsh2xsOPBTmYXz2wOuupu6EJ314/ZKoJUMGF Gh7n6vaQiFPQH+YlJOOis3ieXp/7djatAouuxuaRr9XVd/AsfoDU/U5nWV3WKpxFK/5c sVf9OQX//Clcq7OFZimZEeCUsCfmFMSB144FPoRjkFlP0jjfb1QRyIwqUx6F6HqjsgAb XdVm2BqAkI0fZueXazqfNjUk1j/Hp74DkJVFXYk123k/12U2cY6wXz86G4DbBnJIWN9O +fRw0AukjW9O4pSw5UNeB4gyH0FQBNcKKe7rmVWDagbMR9fhf5lFz2OOa4/zqfASqtTx xrYQ==
X-Gm-Message-State: AOAM533gdlFjTv5M+0yCwUQxR670II887oAbKoZ1hQ5TWDxrcjihIMlS hbp1+DBVPMgWqCTt1ftmMzqK3g/iHNLGMA==
X-Google-Smtp-Source: ABdhPJxIln8+mghyQ9R18mzo9B8KCKT0crzAOy7UJwejERg58lxgxbN/O5MeZLowqN0guC5SwwN9GA==
X-Received: by 2002:adf:9e04:: with SMTP id u4mr21124261wre.302.1596963959106; Sun, 09 Aug 2020 02:05:59 -0700 (PDT)
Received: from localhost ([176.160.172.33]) by smtp.gmail.com with ESMTPSA id e16sm16533203wrx.30.2020.08.09.02.05.57 for <ietf@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Aug 2020 02:05:58 -0700 (PDT)
From: Nadim Kobeissi <nadim@symbolic.software>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3652.0.5.2.1\))
Subject: Re: IESG Statement On Oppressive or Exclusionary Language
Date: Sun, 09 Aug 2020 11:05:57 +0200
References: <B5969C0B-EF25-40CF-BFB4-8E062C90CA24@gmail.com> <90fd8bff-c81c-5518-65c6-b929132a4bdd@comcast.net> <44B55324558FD335BADB4165@PSB> <56fd2677-df6a-8ff2-6093-6e8d42442973@joelhalpern.com> <60160A936BE682CEDE0704E1@PSB> <20200809053037.GV3100@localhost> <5c768c35-edb6-0180-737e-fa0c78cb971d@gmail.com> <20200809063805.GX3100@localhost> <005afe55-7c2c-a0a6-e66f-4513e006ab42@gmail.com> <20200809070448.GY3100@localhost> <20200809084341.GW40202@straasha.imrryr.org>
To: ietf@ietf.org
In-Reply-To: <20200809084341.GW40202@straasha.imrryr.org>
Message-Id: <196BA5B1-92B6-4EC4-897E-F5C14E12647D@symbolic.software>
X-Mailer: Apple Mail (2.3652.0.5.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/giHnigpaA5aZ-RHhpuZ9J9gS9xk>
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: Sun, 09 Aug 2020 09:06:06 -0000

I don’t mean to be pedantic but I also wonder what is going to happen once this ideology hits the chess, Go (the board game) and Othello communities. These communities are centered around “black” and “white” pieces that quite literally fight for “domination” and “control” of a board in a zero-sum game.

I hope I’m not giving anyone ideas here!

Nadim Kobeissi
Symbolic Software • https://symbolic.software

> On 9 Aug 2020, at 10:43 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> 
> On Sun, Aug 09, 2020 at 02:04:49AM -0500, Nico Williams wrote:
> 
>>> individual drafts.  "Master secret" is, of course, used quite
>>> heavily in TLS and TLS-related documents as one example of non-DNS
>>> use.
>> 
>> I have long avoided "master/slave" in my work (except in open source
>> projects where the use predated my involvement and is baked into
>> interfaces).  However, how is "master secret" possibly offensive when
>> there are no "slave secrets"?  Assume I'm not a native English speaker
>> (I'm not).
> 
> Barring sophistry, it is no more offensive, than a master key for a
> physical lock, a Master's degree, a master crafsman (rather than a
> novice or an apprentice), mastering a skill, ...
> 
> The use of "master secret" in TLS is plainly (again barring sophistry)
> beyond reproach.  It is only when "master mumble" is used in constrast
> to "slave mumble", that one might practice restraint in using the former
> in order to avoid also then using or evoking the latter.
> 
> Since "master nameserver" and "secondary nameserver" are not a natural
> pairing, and since in this case "primary" and "secondary" work equally
> well or better, long before this thread, I've already been using primary
> and secondary "nameserver" for many years, not because the older terms
> are plainly offensive, but because the newer ones are a better fit.
> 
> But switching from nameservers to data, the primary nameserver for a
> domain hosts its "master zone file", and this a more apt description
> than "primary zone file" because there's not another managed zone file
> for the domain playing a secondary role.  The copies of the "master zone
> file" on secondary servers are "slave" (or perhaps "replica") copies.
> 
> There are only so many linguistic contortions one should have to go
> through to address rather marginal gains.  After all, it isn't as though
> the word "slave" has fallen out of use in polite company.  We still talk
> about slavery past and present, using that word and not some euphemism.
> 
> There's reason to not use it frivolously, or when better alternatives
> abound, but there's also no reason to avoid its legitimate use when the
> alternatives are worse.
> 
> We can and should be expected to use good judgement, and be polite in
> listening to and giving feedback.
> 
> -- 
>    Viktor.
>