Re: IESG Statement On Oppressive or Exclusionary Language

[[e-mail]]

“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 [e-mail]

On Sunday, August 2, 2020, 16:40, Fred Baker <[e-mail]> 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".
> 
> 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