Subject: [Gendispatch] Fwd: New Version Notification for draft-moore-exclusionary-language-00.txt

From: Keith Moore <[email-masked]>
Date: Wed, 26 Aug 2020 20:27:05 -0400

Ok, after the usual many hours of wrangling with the i-d submission 
tools, my draft is finally posted.

At least in this form I'm intending this draft to be more of a topic for 
discussion than a candidate for publication.

I look forward to the real-time meeting.

Keith

Subject: New Version Notification for draft-moore-exclusionary-language-00.txt
From: [email-masked]
To: "Keith Moore" <[email-masked]>
Date: Wed, 26 Aug 2020 17:25:06 -0700

A new version of I-D, draft-moore-exclusionary-language-00.txt
has been successfully submitted by Keith Moore and posted to the
IETF repository.

Name:		draft-moore-exclusionary-language
Revision:	00
Title:		Avoiding Exclusionary Language in RFCs
Document date:	2020-08-26
Group:		Individual Submission
Pages:		9
URL:            https://www.ietf.org/internet-drafts/draft-moore-exclusionary-language-00.txt
Status:         https://datatracker.ietf.org/doc/draft-moore-exclusionary-language/
Htmlized:       https://tools.ietf.org/html/draft-moore-exclusionary-language-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-moore-exclusionary-language

Abstract:
   It has been asserted that some language in IETF documents is
   "exclusionary" - that it offends some readers or groups of people,
   and/or discourages participation in IETF by doing so.  While there is
   some debate about exactly which language is exclusionary, at least
   some cited examples of such language can credibly have such effects.
   It is believed that most instances of such language are accidental,
   and that most document authors and editors wish to avoid use of
   language that may be offensive.  This memo therefore attempts to
   establish procedures that warn document authors and editors about
   language that may credibly having such effects, and thereby, to
   reduce both accidental and deliberate use of such language.

   At the same time, it is recognized that in some cases there an be
   strong and conflicting opinions about whether or not particular
   language is desirable or appropriate.  IETF's primary function is
   providing technical direction for the benefit of the Internet
   community, rather than social engineering.  If a document can be
   blocked or substantially delayed over disputes about the proprietary
   of language in that document, this can be disruptive to IETF's
   primary function.  This memo therefore makes recommendations to
   prevent such disputes from blocking progress on technical documents.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 27 Aug 2020 17:21:39 +0000

(personal views - no hats)

Here are some comments on your draft, as you requested. While there are aspects of these drafts with which I do not agree, having different I-Ds to consider is an important part of the process of discussion & debate within the IETF -- and I remain hopeful that we will continue to make positive steps forward towards a better and more open IETF.

- Jason

Section 3.2.  Small Benefit, Potentially Large Cost
- I don’t think you have established or quantified that there is actually much, if any, cost of email discussion of terminology, nor that this supposed 'energy drain' on the IETF is either significant or negatively affects the work of the IETF.
- You describe the changes in terminology (e.g. changing master-slave to primary-secondary) as a small benefit. I argue that it is actually hugely & symbolically important as a part of a range of critical & necessary steps towards greater openness, inclusiveness, and attraction/retention of newcomers. As a result, I suggest that if you look at the bigger picture and the cost/benefit of action or inaction on this narrow issue of terminology that the benefit of action is significant and the cost of inaction/intransigence is also significant.

Section 3.3. Potential For Unproductive Distraction
- I think it's a stretch to suggest that the reason RFCs take so long to publish has anything to do with exclusionary language or that this would exacerbate the situation of publishing RFCs. See for example a recent blog about RFC times at https://blog.apnic.net/2020/08/25/opinion-the-making-of-an-rfc-in-todays-ietf/.
- Comparing whether a technical specification in an RFC "SHOULD" or "MUST" be required in a standard to whether to continue using "master-slave" instead of "primary-secondary" does not make sense to me.

Section 3.4.  Late Substitution of Words Considered Harmful
- I don't think there's a risk of confusing readers by doing things like seeking to change from "master-slave" to "primary-secondary".
- Late substitution can be avoided completely by documenting and continuing to document/discuss terminology that can be problematic.

Section 4.1. RFC Editor Requested To Advise Community About Potentially Exclusionary Language
- I agree that the RFC Style Guide is one of the possible tools to address these issues (though perhaps not the only potential tool).

Section 4.2.  Complaints Preferred From Aggrieved Parties
- As others have stated, the entire IETF or at least a wide range of participants or even potential participants can be affected by an issue. It seems unfair to place the sole burden on them when we as a community can take the simple steps to change this like "master-slave" to "primary-secondary". As well, we need to consider the pipeline of future potential newcomers who may see the stubborn perpetuation of such terms as a clear signal that their participation is not welcome or desired, so how would they raise such an issue if they have been repelled from participation in the first place?

Section 4.5.  Working Group Chairs May Limit Discussion of Language
- If a WG follows this advice then they seem to create the conditions you worry about in Section 3.4.  Late Substitution of Words Considered Harmful. IMO the sooner any problematic issues with a draft are raised, the better, regardless of whether those are technical or non-technical. I can tell you from my personal experience writing drafts that the sooner I hear of a concern the better and faster and more easily that I can deal with it.

Section 4.7.  Blocking Based On Language Must be Based On IETF Consensus
- This seems at odds with your Section 4.1. On the one hand you seem to suggest the right approach is solely via the RFC Style Guide but on the other hand say nothing can be done absent an RFC.

Section 4.9.  No Requirement To Revise Existing RFCs
- The IETF updates RFCs and BCPs all the time, even for limited replacement/update of specific terms. We just did a bunch of those when transitioning from the IAOC to the LLC for example, and it was fairly easy.
- As well, why would we want to perpetuate for all time the use of "master-slave" when such a simple change to "primary-secondary" is possible?

<eom>

On 8/26/20, 8:27 PM, "Gendispatch on behalf of Keith Moore" <[email-masked] on behalf of [email-masked]> wrote:

    Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Aug 2020 15:34:21 -0400

> - I don’t think you have established or quantified that there is actually much, if any, cost of email discussion of terminology, nor that this supposed 'energy drain' on the IETF is either signific…

I don't think anyone has convincingly established or quantified the 
benefit of changing the language either.

I'm not saying we shouldn't make any changes;  I think we can and should 
try to improve the language that we use.   Several of the examples on 
https://github.com/ietf/terminology are words for which I can easily say 
"yeah, we should probably stop using that word" simply /because it's the 
right thing to do/ (especially for words that are clearly disparaging of 
some group).  I'm just not sure how much actual benefit will result. I 
suspect it will always be hard to measure that benefit, even decades 
from now.

At the same time I expect that there will be many occasions in which a 
change in terms will be uncontroversial,  particularly if the change is 
originated by subject matter experts rather than imposed from on high.  
IMO the community will willingly avoid using most (but not all) of the 
terms on the https://github.com/ietf/terminology list as long as 
individual working groups or areas are given the choice of whether and 
how to do so.    (And there's certainly some value in aligning use of 
terms between different standards, so some coordination between groups 
dealing with the same subject matter would seem appropriate).

But I don't think that applies to every word on that list, or every word 
that someone might come up with, nor do I think there will always be 
easy/good substitutes.

As for energy drain, I feel like anyone who has been around IETF for 
very long should realize that there are some kinds of hot button issues 
that have a strong tendency to generate far more heat than light.  
Censorship certainly seems like one such issue.

Also, many disputes in IETF get resolved because there's an objective 
technical benefit to the approach chosen, over other identified 
approaches.   IMO, the use of language is not an issue that uniformly 
lends itself to that kind of conflict resolution.

> - You describe the changes in terminology (e.g. changing master-slave to primary-secondary) as a small benefit. I argue that it is actually hugely & symbolically important as a part of a range of c…

You seem to be repeatedly citing a single, easy example to argue 
something much broader.   I think the cost of changing terms will differ 
from one term to another and one subject domain to another.  So I find 
an argument of the form "changing master-slave is easy" (which is 
actually not clear) "...therefore changing all terms will be easy" 
unconvincing.

I do acknowledge the potential for benefit, especially over the long 
term.  I also suspect that the benefit may compound over time, and 
decades from now the benefit may be far more apparent than it will be in 
say 5-10 years.  But I think it's hard to quantify "symbolically 
important" benefits.

But more broadly, people have spoken of "fixing" long term injustices 
that we really cannot fix with these small actions.  By saying the 
benefit is small, part of what I'm saying is that it's small in 
comparison to the changes that need to happen elsewhere in society.

Something that I firmly believe, but didn't really touch on much in my 
draft, is that (even though we should make at least some of these 
changes), /we should //not//make these changes in order to feel better 
about ourselves as privileged persons/.  Because if that's our goal, 
then we're very likely to get the solutions wrong, all while patting 
ourselves on our collective backs for our noble efforts.   That's part 
of why I said we should approach this with humility.  It's also part of 
why I said that the complaints should ideally come from the parties 
actually aggrieved by our language, rather than from people claiming to 
act on those parties' behalf.      Because both the harm done, and the 
degree of change needed to remedy that harm, will probably be clearer to 
those parties.

> - I think it's a stretch to suggest that the reason RFCs take so long to publish has anything to do with exclusionary language or that this would exacerbate the situation of publishing RFCs. See fo…

Oh, I certainly didn't intend to argue that.   What I would say instead 
is that RFCs get held up for a wide variety of reasons, some of them 
arbitrarily imposed after a working group has finished.   So I'm arguing 
against creating more excuses to arbitrarily hold up RFCs.

More clearly, I expect IESG to make technical judgments about fitness of 
protocols.   But I don't think it's appropriate for IESG to be language 
police, except when following clearly established IETF consensus.

> - Comparing whether a technical specification in an RFC "SHOULD" or "MUST" be required in a standard to whether to continue using "master-slave" instead of "primary-secondary" does not make sense t…

It's just a perhaps-familiar example of how people can be overzealous in 
interpreting rules.   I am not sure why people do it, but I've seen it 
happen many times.   Maybe some people over-interpret rules out of a 
desire to show how loyal/obedient they are, but often not a good thing.

> - I don't think there's a risk of confusing readers by doing things like seeking to change from "master-slave" to "primary-secondary".
I disagree, and again, that one example is not representative of all cases.
> - Late substitution can be avoided completely by documenting and continuing to document/discuss terminology that can be problematic.
"[A]voided completely" seems like an exaggeration, unless perhaps you 
have some processes in mind that I'm not aware of.   I do think that 
late substitution can be minimized if we realize it's a risk that needs 
to be managed.
> - As others have stated, the entire IETF or at least a wide range of participants or even potential participants can be affected by an issue. It seems unfair to place the sole burden on them when we as a community can take the simple steps to change this like "master-slave" to "primary-secondary".

Again, the trivializing example.

But I wasn't intending to "place the sole burden" on anyone. Rather I'm 
saying that /when people take it upon themselves to be offended on 
behalf of other people, or to "fix" problems for other people of which 
they lack personal experience, //they quite often get it wrong//./   One 
of the ways they get it wrong is by being overzealous, and one of the 
reasons that people get it wrong is that the people arguing for such 
changes (often insistently) are trying to make themselves feel better 
(or more virtuous) rather than actually addressing a harm that they know 
firsthand through experience.

Another way to look at this is: /while discouraging some words in favor 
of others might be good, discouraging or excluding//more words is not 
inherently better//, and we don't want to create conditions that enable 
people to exclude as many words as possible/.

>   As well, we need to consider the pipeline of future potential newcomers who may see the stubborn perpetuation of such terms as a clear signal that their participation is not welcome or desired, so how would they raise such an issue if they have been repelled from participation in the first place?

This argument keeps being made and I've seen no credible support for 
it.   We need to stop citing this as justification until there's clear 
evidence to support it.  I'm not saying we shouldn't change our language 
as there are clearly some cases for which we should.   But other 
potential changes have significant costs (both in the energy required 
and in the harm done to the readability of our specifications) and we 
need to not be making them for dubious reasons.

> - If a WG follows this advice then they seem to create the conditions you worry about in Section 3.4.  Late Substitution of Words Considered Harmful. IMO the sooner any problematic issues with a dr…

I did say that issues could be raised at any time.    The point is to 
not have endless discussion about it.   I actually think that if issues 
are raised early, then there's a good chance that the people raising the 
issue can work things out with document authors/editors early.

I will admit that I'm not sure how best to handle such a discussion if 
it gets contentious and another proposal for how to do so might be 
better.   Consider this a placeholder and alternative suggestions are 
welcome.   Of course, it's not unusual for WG chairs to try to manage 
discussions that are blocking other progress, or to try to keep the same 
issues from being raised again and again in the absence of new information.

> - This seems at odds with your Section 4.1. On the one hand you seem to suggest the right approach is solely via the RFC Style Guide but on the other hand say nothing can be done absent an RFC.

I would draw a distinction between: (a) style advice for use by document 
authors/editors, including suggestions about which words to avoid and 
potential substitutes, versus (b) blocking document progress based on 
presence of certain words.   I'm fine with advice that allows 
authors/editors some discretion.   But I think IESG should not be able 
to block or significantly delay documents based on the presence of 
words, without IETF Consensus to back them up.

> - The IETF updates RFCs and BCPs all the time, even for limited replacement/update of specific terms. We just did a bunch of those when transitioning from the IAOC to the LLC for example, and it wa…

Revising many RFCs requires a Herculean effort for often-dubious benefit 
and IMO we do it far too often.   It's not a matter of just changing a 
few words.  Every erratum needs to be discussed and resolved.  Often 
there are long discussions about how to split particular hairs, how to 
reconcile minor incompatibilities between implementations of the old 
RFC, implementations of the new RFC, and existing practice that deviates 
from both.    It's typically necessary to not only sync the revised RFC 
with everything else that it references (some of which are moving 
targets).   And there's generally less community interest in doing due 
diligence on a revised RFC than there was for the original RFC - unless 
perhaps there are significant bugs to be fixed.   And of course there's 
the usual WG, IESG, and RFC Editor processing that is done with every 
RFC.  It hardly seems worth the trouble if there's not a good reason 
(like an interoperability failure) to change things.

So I maintain that gratuitous revision of RFCs is nearly always a Bad 
Idea.   We should find better ways to update RFCs than by revising them 
wholesale.

Keith

---

From: "John Levine" <[email-masked]>
Date: 27 Aug 2020 17:08:37 -0400

In article <[email-masked]> you write:
>>   As well, we need to consider the pipeline of future potential newcomers who may see the stubborn perpetuation of such terms as a clear
>signal that their participation is not welcome or desired, so how would they raise such an issue if they have been repelled from participation
>in the first place?
>
>evidence to support it. ...

I've seen plenty of examples of people who show up briefly and are
repelled by the who-the-hell-are-you attitude of some of the mail
replies. (I am surely not innocent here.)

As a rather stale example, some years ago I posted a note to dnsop
suggesting that with DNSSSEC, a DNS cache could synthesize negative
answers to queries rather than asking the authoritative server, which
would avoid some cache churn problems I anticipated with IPv6 DNSBLs.
I promptly got a bunch of answers telling me that's not what DNSSEC is
for and I was stupid even to suggest such a thing. Scroll forward a
few years, that's now RFC 8198. Lucky for me my social skills are so
poor that I didn't realize that being called stupid was an insult.

This particular issue is considerably larger than whether we should
say "slave" in our documents.

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Thu, 27 Aug 2020 17:29:47 -0400

On 8/27/20 5:08 PM, John Levine wrote:

> replies.

So have I, but I think the intersection between that problem, and the 
use of words currently under discussion, is small.

(And yes, we should do better.   But I also see plenty of examples in 
which people who really don't have the background are treated with 
courtesy and patience, and sometimes those folks end up being valuable 
contributors.)

> say "slave" in our documents.

Yes, I expect so.

Keith

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 28 Aug 2020 13:23:13 +0000

It's tough, balancing "be informed of the history" with "welcoming new contributions" and we should be able to do a better job.  (Pity the poor noob who steps into DNS for example.)  But that's probably off-topic for this list.