Re: IESG Statement On Oppressive or Exclusionary Language

[Erik Nygren <[e-mail]>]

+1 to Phillip here

I feel there is value in publishing a best-practice guide here to avoid the
need to keep
litigating this conversation over and over.  One major value will be in
helping
give some "style-guide" recommendations to non-English speakers
as well as to help bridge between our varying cultural backgrounds.
I can see why people outside the U.S. may not have a local history
with systemic racism against people who are black and thus may
not see the importance of shifting the language here.

For example, I didn't understand the controversy about
whitehat/blackhat until I talked to some coworkers who
pointed out the concern that associating "black" with "illegal"
furthers a long history of injustice within the US justice system
and furthers racial stereotypes in an American context.
I agree with Richard's comment above that we should not
be trying to invalidate the experience of others
and should be listening to them.

It is important for us to recognize that the people who introduced
master/slave and whitelist/blacklist into our technical lexicon did
not have ill intent, and going forwards we generally should be
forgiving of accidental use.  The goal here shouldn't be to forbid
speech, but to help provide guidance towards a technical
lexicon which is more inclusive.

It will also be valuable to have some new standard recommendations.
As companies and software projects change terminology, having
consistency may help with interoperability of both technology
and human communications.

The cultural context matters, and with the IETF as a diverse
organization with people from around the world, standardized
guidance can help us be more sensitive to others.
For example, I would hope that we'd all agree that we
should be avoiding slurs against genders and ethnic groups
in IETF documents? If we were to discover that some technical
term was a ethnic slur (perhaps not even in American English),
I'd also hope that we'd have guidance to help authors avoid
using it and provide recommendations for a new term to use instead.

I agree with some others earlier in this long thread that it would
be good to have guidance/recommendations to draft authors, with RFC Editor
actually providing a final check prior to publication.

That doesn't mean we necessarily need to go back and change existing
documents, although
there may be cases where we want to do so over time (and in some
cases may be prevented from easily doing so).  As an example, rfc1760
and rfc2289 have word lists that contains quite a few words that I really
hope would not be included if such
a word list were to be compiled today.  That doesn't mean it's possible to
change
given how they are baked into the protocol, but I might hope that if we
were
creating a new version today that some more thought would be given
to avoiding words that are offensive to some users (especially given that
some other words do seem to have been excluded from those word lists)
or finding a better approach that didn't involve needing to pick a list
of only "good" words.



On Mon, Jul 27, 2020 at 1:51 PM Phillip Hallam-Baker <[e-mail]>
wrote:

> I don't see a need to litigate the phrase y'all absent a plausible reason
> such a word would be used in an RFC or standards process document.
> Colloquial language is best avoided regardless.
>
> On the broader topic, I recall a very hotly contested issue that consumed
> much time in Westminster and at cabinet level a few years back where the
> absence of females serving in a particular role in a document was used to
> argue that they must never be allowed to serve in that role: ordination of
> women priests.
>
> Now I recall that at the very same time the CoE was going through that
> issue, the use of gender neutral language in specs was being dismissed by
> some people (all men) on the basis it was 'nonsense'.
>
> Language has consequences.
>
> Nor are facts or history the relevant measure, the question should be
> whether the terms are used to give offense. In the UK, to 'Welch' on a bet
> means not paying after losing and the name goes back to a pair of bookies
> called the Welch brothers who did a runner after taking a large number of
> winning bets in the 1860s. But that is now a term that is avoided because
> in speech it is easily mistaken for a slur on the Welsh.
>
> There are numerous cases of this type where no ill intent might be
> intended but might easily be taken. But why introduce unnecessary
> ambiguity? The whole point of the IETF process is to produce clarity.
>
> Whitelist and Blacklist are best avoided because they carry no semantic.
> The association white=accept is purely cultural. Acceptlist and Blocklist
> are preferable because they provide more clarity.
>
> There is also a technical argument to be made against at least 80% of the
> uses of master/slave: the terms simply do not reflect the technical
> reality. The term is ambiguous in any case, the online dictionary I just
> scanned has six separate meanings as a noun plus three adjectives and two
> verbs. That is not a word to use in a spec.
>