Re: IESG Statement On Oppressive or Exclusionary Language

[Fred Baker <[e-mail]>]

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 <[e-mail]> wrote:
> 
> On 02/08/2020 07:38, Fred Baker wrote:
>> Sending again because I left the intended attachment off. My error.
>> 
>>>> On Aug 1, 2020, at 11:10 PM, Fred Baker <[e-mail]> wrote:
>>> 
>>> 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".
> 
> 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
> 
>>> 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 <[e-mail]> 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
>> 
>> 
>>