Re: IESG Statement On Oppressive or Exclusionary Language

Viktor Dukhovni <ietf-dane@dukhovni.org> Sun, 09 August 2020 08:43 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 EB8613A0BCF for <ietf@ietfa.amsl.com>; Sun, 9 Aug 2020 01:43:43 -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 L5tKiVHuh2fH for <ietf@ietfa.amsl.com>; Sun, 9 Aug 2020 01:43:42 -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 D12003A0BCE for <ietf@ietf.org>; Sun, 9 Aug 2020 01:43:42 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 3B9712B7983; Sun, 9 Aug 2020 04:43:41 -0400 (EDT)
Date: Sun, 09 Aug 2020 04:43:41 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org
Subject: Re: IESG Statement On Oppressive or Exclusionary Language
Message-ID: <20200809084341.GW40202@straasha.imrryr.org>
Reply-To: ietf@ietf.org
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20200809070448.GY3100@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/a_hGQplJkppH5s5CY7DRDjy0lwU>
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 08:43:44 -0000

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.