Re: Diversity and offensive terminology in RFCs

Mukund Sivaraman <muks@mukund.org> Thu, 20 September 2018 12:02 UTC

Return-Path: <muks@mukund.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 6F8B2130E9A for <ietf@ietfa.amsl.com>; Thu, 20 Sep 2018 05:02:20 -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, 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 VxzEMjw9i_tW for <ietf@ietfa.amsl.com>; Thu, 20 Sep 2018 05:02:17 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id EAB39130E85 for <ietf@ietf.org>; Thu, 20 Sep 2018 05:02:16 -0700 (PDT)
Received: from jurassic (unknown [27.5.183.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id C317D32C0921; Thu, 20 Sep 2018 12:02:14 +0000 (UTC)
Date: Thu, 20 Sep 2018 17:32:10 +0530
From: Mukund Sivaraman <muks@mukund.org>
To: Niels ten Oever <lists@digitaldissidents.org>
Cc: ietf@ietf.org
Subject: Re: Diversity and offensive terminology in RFCs
Message-ID: <20180920120210.GC24100@jurassic>
References: <cafa1282-ae6a-93de-ea4a-d100af28d8b8@digitaldissidents.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <cafa1282-ae6a-93de-ea4a-d100af28d8b8@digitaldissidents.org>
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Hb9v16qo8zGb0Rp7LmHnHSnv6co>
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: Thu, 20 Sep 2018 12:02:21 -0000

In my very early DNS days, I used to feel uncomfortable typing "slave"
though I've become used to it now that I don't think twice.

We've had some discussions about this in my previous DNS team about
"master" and "slave" in DNS terminology. Note that the preferred terms
now are "primary" and "secondary" respectively per RFC 7719. I'll use
master and slave below because I want the descriptions to make sense in
that context.

In DNS, the meaning of master/slave, from a driver perspective, doesn't
strictly capture what happens in the DNS protocol. It is the slave that
queries the master to do something for it (return zone data), and the
master does work on the slave's behalf. It is the slave that drives it -
the master strictly cannot instruct the slave to do something (NOTIFY is
a notification that a slave can avoid or not even handle).

>From a coupling perspective, though the slave for a zone synchronizes
its zone data to the data on the respective master, there's no
requirement in DNS for the slave to be tightly coupled to the master.
i.e., it is the slave's choice whether it feels like updating this
moment, and it may not do so, whereby after a time interval it should
stop serving the zone.

There is also another concept of "master" in DNS which is the master
file. Though it describes presentation format (a syntax) for zone data
storage, the concept of master here is used analogous to "master copy"
e.g, for a video or audio recording, i.e., something like the main copy
of the data.

When there are other and better terms to describe the entities such as
"primary" and "secondary", there's no need to stick to words that offend
some people. It may not offend you, but you may not have lived a life in
a family/community where such things have affected you.

IMO, there's no need to drive out all references to master/slave usage,
but newer usage should try to find more appropiate terms, and software
should allow usage of alternate terms. If "slave" is the only English
term that you can find, just ask a colleague.

These are generic usage terms and do not identify a product such as a
trademark to cling onto them. E.g., GIMP (GNU image manipulation
program) gets a lot of complaints again and again about its name. But
re-branding it is not a small feat - it would break a lot of things. One
could say GIMP has redefined the term too (e.g., if you do a web search,
you'd find very results of the derogatory usage). Master/slave is not
like that, at least in my limited area of DNS.

		Mukund