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 <fredbaker.ietf@xxxxxxxxx> 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 <iesg@xxxxxxxx> 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
