Subject: Re: IESG Statement On Oppressive or Exclusionary Language

From: Fred Baker <[email-masked]>
Date: Sat, 1 Aug 2020 23:10:49 -0700

I am following up on the IESG's invitation of comments from the community.

Attached, please find the result of an grep -w -f ... looking for the words discussed in draft-knodel-terminology:
	Master
	Slave
	Blacklist
	Whitelist

If we are going to enact the proposed policy, I would suggest that we don't try to change RFCs that have already been published, or documents on any kind that derive from another source. The IESG's note comments that these are "complex" to perform, and I would agree with them. I would add that in any context in which a defined term is being used, use the defined term. If you want to change the term, you need to be very clear about it. What we can do that makes sense, IMHO, is not use them in future documents unless their origin is clarified.

I do take some exception to the statement, made in Mallory's draft, that the terms are "inaccurate". I suspect that the terms are being used in a manner entirely in keeping with their definitions. A "master" controller, per lawinsider.com, is "a controller supervising the operation of several local controllers.". Per yourdictionary.com, a "master program" I "The program in control of the machine.". Looking at several sources ("google is your friend"), a slave changes its configuration to agree with its master, and behaves accordingly. Again, Google is your friend, but a blacklist is according to several definitions a list of identities to be denied access, and a whitelist is a list of identities to be accorded access. If the operation is consistent with ambient definitions, it is not "inaccurate". It may be "other than preferred", but it is not "inaccurate".

There is no human being identified by the color of their skin or by the relationship between employer and employee; if there were, are are a few other colors and operating modes that would have to be discussed. There is also long historical precedent, stretching back at least to the period prior to Moses leading Israel out of Egypt.

I have made these comments in hrpc. They were dismissed as originating from a "white male". The issue of exclusionary language in the course of hrpc was reported to the chair of that group, and was not acknowledged. 

> On Jul 23, 2020, at 9:35 AM, The IESG <[email-masked]> wrote:
> 
> The IESG believes the use of oppressive or exclusionary language is 
> harmful.  Such terminology is present in some IETF documents, including 
> standards-track RFCs, and has been for many years. It is at odds with 
> our objective of creating an inclusive and respectful environment in the 
> IETF, and among readers of our documents.
> 
> The IESG realizes that the views of the community about this topic are 
> not uniform. Determining an actionable policy regarding problematic 
> language is an ongoing process. We wanted to highlight that initial 
> discussions about this topic are taking place in the general area (a 
> draft [1] is slated for discussion in GENDISPATCH [2] at IETF 108).  
> Updating terminology in previously published RFCs is a complex endeavor, 
> while making adjustments in the language used in our documents in the 
> future should be more straightforward. 
> 
> The IESG looks forward to hearing more from the community, engaging in 
> those discussions, and helping to develop a framework for handling this 
> issue going forward.
> 
> [1] https://datatracker.ietf.org/doc/draft-knodel-terminology/
> [2] https://www.ietf.org/proceedings/108/agenda/agenda-108-gendispatch-03
>

---

From: Fred Baker <[email-masked]>
Date: Sat, 1 Aug 2020 23:38:48 -0700

Sending again because I left the intended attachment off. My error.

> On Aug 1, 2020, at 11:10 PM, Fred Baker <[email-masked]> wrote:
>

---

From: [email-masked]
Date: Sun, 2 Aug 2020 08:45:54 +0000 (UTC)

“I have made these comments in hrpc. They were dismissed as originating from a "white male". The issue of exclusionary language in the course of hrpc was reported to the chair of that group, and was not acknowledged. “

and that is why, as someone identified as a white male, I don’t engage with the hprc list.
Having different voices that are privileged over others does not change the fact that some voices are being privileged.
Lloyd [email-masked]

On Sunday, August 2, 2020, 16:40, Fred Baker <[email-masked]> wrote:

---

From: tom petch <[email-masked]>
Date: Sun, 2 Aug 2020 21:25:10 +0100

On 02/08/2020 07:38, Fred Baker wrote:
>> If we are going to enact the proposed policy, I would suggest that we don't try to change RFCs that have already been published, or documents on any kind that derive from another source. The IESG's note comments that these are "complex" to perform, and I  would agree with them. I would add that in any context in which a defined term
> is being used, use the defined term. If you want to change the term, you need to
> be very clear about it. What we can do that makes sense, IMHO, is not use them
> in future documents unless their origin is clarified.
>>
>> I do take some exception to the statement, made in Mallory's draft, that the terms are "inaccurate". I suspect that the terms are being used in a manner entirely in keeping with their definitions. A "master" controller, per lawinsider.com, is "a controller  supervising the operation of several local controllers.". Per
> yourdictionary.com, a "master program" I "The program in control of the
> machine.". Looking at several sources ("google is your friend"), a slave changes
> its configuration to agree with its master, and behaves accordingly. Again,
> Google is your friend, but a blacklist is according to several definitions a
> list of identities to be denied access, and a whitelist is a list of identities
> to be accorded access. If the operation is consistent with ambient definitions,
> it is not "inaccurate". It may be "other than preferred", but it is not
> "inaccurate".

Fred

I note that a substantial proportion of this usage of 'master' has no 
usage of 'slave' AFAICT.  TLS and other security protocols have 'Master 
Secrets' and XML has master documents but I see no usage of a related 
'slave' which suggests to me how much this kind of proposition by the 
IESG can go so wrong.

Tom Petch

>>> [1]https://datatracker.ietf.org/doc/draft-knodel-terminology/
>>> [2]https://www.ietf.org/proceedings/108/agenda/agenda-108-gendispatch-03
>
>
>

---

From: Fred Baker <[email-masked]>
Date: Sun, 2 Aug 2020 14:20:44 -0700

And for the record, this doesn’t originate in the IESG. It comes from HRPC.

Sent using a machine that autocorrects in interesting ways...

> On Aug 2, 2020, at 1:25 PM, tom petch <[email-masked]> wrote:
> 
> I note that a substantial proportion of this usage of 'master' has no usage of 'slave' AFAICT.  TLS and other security protocols have 'Master Secrets' and XML has master documents but I see no usage of a related 'slave' which suggests to me how much this kind of proposition by the IESG can go so wrong.
> 
> Tom Petch
>

---

From: Melinda Shore <[email-masked]>
Date: Sun, 2 Aug 2020 13:34:57 -0800

> And for the record, this doesn’t originate in the IESG. It comes from HRPC.

It did not come from HRPC, in the sense that there was not, to
my recollection (which, granted, may be flawed), an RG decision
to request publication in the IETF stream.  It's "draft-knodel,"
not "draft-hrpc."

For the most part people seem to be arguing from their own
experiences and from what they believe to be true, rather than
addressing the actual contents of the draft.

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 3 Aug 2020 06:35:07 +0900

> And for the record, this doesn’t originate in the IESG. It comes from

 From the charter:

	standards and protocols can enable, strengthen or threaten
	human rights, as defined in the Universal Declaration of
	Human Rights (UDHR) [1] and the Internaional Covenant on
	Civil and Political Rights (ICCPR) [2], specifically, but
	not limited to the right to freedom of expression and
	the right to freedom of assembly.

it shouldn't have behaved so US centrically.

						Masataka Ohta

---

From: Nadim Kobeissi <[email-masked]>
Date: Sat, 8 Aug 2020 05:14:45 +0200

This entire subject is so toxic, unnecessary and divisive that it could pass for a Trojan Horse (hopefully not, too, an “offensive” term to Trojans) with the specific intent of dividing and IETF, sowing discord between its members and to introduce notions of sectarianism and tribalism that were on their way *out* of the IETF since its diversification from a US-dominated organization and into a truly international and truly inclusive organization.

I became familiar with the IETF after humble beginnings as a Lebanese immigrant. At no point have I ever witnessed anyone being “excluded” or “hurt” by the usage of terms such as “master program”, “master branch”, “blacklist” or “whitelist”. None of these terms have any historical relationship to specifically the history of slavery in the United States of America. They are simply technical terms.

There have been repeated calls for an empirical survey to actually determine if there are people who feel in any way disenfranchised by these terms. These calls have been dismissed, ignored or even suggested to be certainly in bad faith. In fact, the response to these calls has consistently been that unless we accept that surely this harm must exist, then we as individuals lack empathy, cannot think correctly, and hold sin in our hearts that must be purged. The legitimization of such religious and cult-like rhetoric in the IETF is disturbing. The dangers of legitimizing this religious thinking must be recognized, given a name and must be quelled before the impact on the IETF’s productivity becomes infected with cult-like notions.

In fact, the way that people who reasonably disagree with this topic have been treated for expressing their views is exponentially more “exclusionary” than any exclusion I’ve seen by virtue of using the term “blacklist” somewhere.

It is shameful to waste so much of people’s time and to cause so much damage to the collective psychology of the IETF in order to push through requested changes that seem entirely borne out of some personal guilt complex that is not necessarily shared by other IETF members or indeed the global community, who largely sees this as an American cultural phenomenon that defies explanation. Virtually nobody outside of North America cares about this topic at all. We’re not growing up in the Middle East feeling “marginalized” because we see the term “whitelist”. Even the suggestion of this is so patronizing that I wonder if the people who think like this view the entire world as constituted of children.

This entire topic is harmful to the IETF’s collective psychology and its ability to collaborate. The IESG should follow its mandate and stop sowing discord among IETF members with these unnecessary, tribalistic and mentally troubled topics. This discussion as a whole has been nothing but a net harm to the IETF, and is causing quantifiable damage to the ability of its members to work together to produce a more performant, secure and indeed inclusive Internet.

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

> On 23 Jul 2020, at 6:35 PM, The IESG <[email-masked]> wrote:
>