Subject: Re: [Gendispatch] draft-knodel-terminology-02

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 3 Jul 2020 11:30:37 +0100

Thanks, Niels and Mallory, for having the strength to persevere with this important topic. I would like to see the IETF reach some fairly rapid resolution on the thrust of your work so that we can advise authors and the RPC on the way we want to use language.

I have some lengthy thoughts, below. I reviewed the formatted markdown at https://github.com/IRTF-HRPC/drafts/blob/master/draft-terminology.md based on commit 150a2a7 on 2020-06-18.

My notes were compiled as I read the document and so my thoughts developed as I read/wrote. 

Best,
Adrian

===

The big thing that stuck out when I got to the end was, "Are you trying to capture terms that should be substituted, or are you just providing two blatant examples in an attempt to drive the process and discussion forward. I think it is the latter, but this is very far from evident as you start into the document. This would benefit from a very clear statement right at the top of the document.

---

At several points I worry about your use of words like "racist". I fear that that word carries a lot of emotion at the moment. And it is often felt to be accusatory. I would suggest taking a more neutral tone with "a term that some people may find unacceptable or offensive based on its connotations or etymology." Indeed, I think you don't want to be limited to only some *ist terms, but want to eliminate all discriminatory or divisive language. (Note that we found with RFC 7776, if you try to list every way that someone can get it wrong you end up missing out one thing and thereby appear to condone it.) I'm sure you want to call out language for what it is, but I would caution that your objective is to remove the use of language that is of itself racist, or that engenders or supports racism, without insinuating that someone who has used that term without knowing any better is actually a racist person. That seems, to me, a whole different debate that it is not worth having and which will distract from the work you are trying to do.

There is a delicate balance in the use of "some people may find this offensive" because we do need to avoid victim-blaming. And maybe it is not the offense that is given that we actually care about. We care about the broader impact of the use of the word: how it supresses people directly, and how it builds a culture or overt or subconscious prejudice. So there may be other words that we should use. In fact, perhaps we don't want blame in any direction: we just want to stop using those words.

---

Title

I would suggest making it clearer that your scope is specifically drafts and RFCs. I know it would be nice to apply it to everything, or at least everything the IETF does, but I believe in achievable goals! How about...
 
"Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs"

---

Abstract

Conversely to the previous point (😊) the Abstract just says "RFCs". I think we want the scope to be Internet-Drafts. In fact, although RFCs are a matter of record, it is possible that I-Ds have more effect on the day-to-day nature of the IETF. 
 
Also, I don't believe at this stage you should try to change language in RFCs that have already been published. I think the scope of this document should explicitly rule out changing any published RFCs. 

That leaves me suggesting the Abstract should read (including some fixes for style)...
 
This document argues for moving away from certain specific language conventions sometimes used by RFC authors and the RFC Production Centre in order to encourage the use of more inclusive terminology in Internet-Drafts that are work in progress, and in new RFCs that may be published in any of the RFC series. The document also provides examples of inclusive terminology as precise alternatives for these conventions.
 
---
 
General point. 
 
I like how you have used positive language (for example, in the Abstract). There is a difference (IMNSHO) opinion between "inclusive terminology" and "terminology that is not exclusive". This may be petty pedantry on my part, or (and I'd be happy to be told this is the case) it may be that I am not correctly aware of the nuances.
 
I would find it gentler to say "...encourage the use of less-exclusive terminology..."
 
That is, our objective is to avoid being exclusive, rather than to be explicitly inclusive.

Let's take the "blacklist" example. Your alternatives are all reasonable, but they are not "inclusive". The very nature of the lists described are exclusive, and the alternative names are not constructed to give a feeling of inclusion. But, the alternative names *are* less exclusive.

My point, in summary, is to frame everything in the context of "exclusive" and "not exclusive" rather than using "inclusive".

---
 
Introduction
 
You have not provided an attribution to the first quote, so I presume that you are taking it from the same source as the second quote (i.e., RFC 7322). But you have changed something! 7322 says, "The ultimate goal of the RFC publication process is to produce documents that are readable, clear, consistent, and reasonably uniform." I think that might be considered a bit near the edge.
 
You are missing a close quote on the second passage from RFC 7322
 
Your language here jumps around a bit between "IETF" and "IETF/IRTF". I think your target (as I expressed in my proposed changes to the Title and Abstract) is all Internet-Drafts and RFCs. You want to cover all streams and all RFCs.
 
The final paragraph basically says "We only actually found two sets of terms in use that need attention." Is that really the case? Or is this just a starting point for this draft with the anticipation of finding further problematic terms? If you are providing specifics for action, I would drag personal pronouns out of "Other Considerations" and give it its own section with the same relevance as b/w and m/s, and I would also call out terms like "black hole" (in the sense of where traffic disappears to), "blackhat", and even "invalid". But this is part of the big questions about the document's intent - *if* it is your intention to add more terms as you do more work on the document, then say so up front, if, OTOH, your objective is to get to the recommendations, then say that and state that you are only "providing some notable examples."

I hate (hate, hate) Introductions that tell me what I am going to find in each section. There is a Table of Contents for that. I think this might be a carry-over from writing academic papers (where I am always told off for not including it), and while it is not uncommon in Internet-Drafts, it feels unnecessary and a bit pedagogical.
 
So, a suggested rewrite of the Introduction is...
 
According to {{RFC7322}}, "The ultimate goal of the RFC publication process is to produce documents that are readable, clear, consistent, and reasonably uniform," and one function of the RFC Editor is to "[c]orrect larger content/clarity issues; flag any unclear passages for author review." Documents that are published as RFCs are first worked on as Internet-Drafts.
 
Given the importance of communication between people developing Internet standards and related documents, it is worth considering the effects of terminology that has been identified as exclusionary. This document argues that certain obviously exclusionary terms should be avoided and replaced with alternatives.
 
This document presents arguments for why exclusionary terms should be avoided in Internet-Drafts and RFCs, describes the problems introduced by some specific terms, and proposes alternative language. The terms discussed in this document include "master-slave" and "whitelist-blacklist".

Accepted and inserted, with small change at the end.

---
 
Terminology
 
I think you only use the special terminology in the "Recommendations" section.
This is an Informational document and you are making recommendations. That makes the use of 2119 language a bit iffy. 
I would suggest dropping this section and using lower case in the "Recommendations" section, but it's not a big deal.

---
 
Terminology and Power at the IETF
 
Again, I'd like you to consider whether you are targeting the IETF or "Internet-Drafts and RFCs".
 
Sometimes where you have "RFCs" you should have "Internet-Drafts and RFCs". Where you are talking about actions by the RFC Editor, then sure, that only applies to "new RFCs", but surely we want authors to act as well?

I confess I would not have written this section in this way. But that is personal style. Let me, however, flag a few of the lumpier bumps from my PoV.
 
- Para 1. "This implies that..." I don't think it implies what you claim it does. It talks about the goals of rhetorical theory, not the desirability of rhetorical theory or the outcomes of its goals. And actually, I think most readers will be lost by the time they see "rhetorical theory": is this a document about rhetorical theory or about terminology, power, and inclusive language in the Internet-Drafts and RFCs? I think I would strip from the top of the paragraph down to "In order to effectively communicate..." Obviously that means you have to fix up "She continues". [BTW I stumbled over "language use". The English is correct, but my eyes wanted to see "language used"] The alternative here would be to make clearer *why* we should apply rhetorical theory in the case of RFCs and Internet-Drafts.

- Para 2. A major problem with the terms "racist" and "sexist" is that they are understood by many people to be conscious or wilful acts founded on beliefs. The concept of ingrained or unconscious racism and sexism is much harder to grapple with for most people. See my introductory text. This may be handled by saying (perhaps in the Terminology section) something like, "We consider terms that serve to oppress or diminish people, or that tend to reinforce conscious or unconscious prejudices to be 'racist' or 'sexist' language, and we use those descriptions through-out this document."

- Para 3 s/avoided but/avoided, but/

- Para 4 s/linguistics and power and attempts/linguistics and power, and attempts/
 
- Para 4 "attempts to '...promote awareness that may lead to eventual wide-spread change" {{BrodieGravesGraves}}'. I think that you are doing more than promoting awareness in your "Recommendations" section. Maybe '...attempts to "promote awareness that may lead to eventual wide-spread change" {{BrodieGravesGraves}} and suggests first steps for actions that may remedy the inadvertent use of undesirable terms'.

- Para 4 s/To that effect, below is a tersely written list/To that end, the list below is a tersely written set/

- Para 4  A pedant asks: Are we really only worried about "offensive metaphors". Actually, please say "metaphors that may cause offense" since (again) the question of intent and subjective vs objective offense is best avoided in this community. But anyway, my point was, what about similes? And indeed, is "blacklist" even a metaphor (rather than a metaphorical construct) - it's not as though there is such a thing as a black list and we have stolen the term. Perhaps just stick with "term" and "language". [BTW, this opens up another topic of discussion that could easily be a rat-hole (oops, there's a metaphor): the use of metaphors in any cross-cultural or technical communication tends to be poor style and should be avoided. While it would be great to see our style guide recommending against the use of metaphors in general, I don't think this is the objective of this piece of work.]
 
- Para 4 "encouraged to correct larger content and clarity issues with respect to offensive metaphors"
      - What does "larger" mean? Isn't it unnecessarily subjective?

- bullet 4 Do we have to have "gender-non-conforming"? By suggesting that this both a requirement to conform and some situation that is "normal" it is, itself, an offensive term where I come from. I struggle to find the correct term to use here, but my advice would be that where the short term is difficult, it is better to use more words to describe the situation. I could only come up with "people who make their own choice as to their gender representation" and I'm not satisfied with that.
 
---
 
Master Slave

I found para 3 very interesting and, erm, stimulating. But is it the discussion you want to have here? If I can argue about whether "the role of the master was to abdicate" was anything other than sarcasm, then I am arguing about the wrong topic. Why give me that opportunity? Do you need this paragraph?
 
---

Master Slave
 
The final paragraph of this section is striking and true. Does it belong here (it is not in any way specific to the Master Slave issue) or should be further up the document where you can use it to set context that there is work needed. Indeed, in this paragraph you provide a quote about PC and minorities, but you state specifically that this is racism. It may be, but the quote appears to be more general and one that needs to be used to cover the whole document. Or perhaps it should be in both places.

---
 
Suggested Alternatives (to Master Slave)
 
But s/alternatives for the master-slave relationship/alternatives for the term master-slave/
 
I would strongly suggest to remove from this list any suggestions that are also metaphors that have overtones that are not helpful:
 - Leader-follower
 - Coordinator-worker
 - Parent-helper

The penultimate paragraph is confusing to me.
"Since the use of master-slave is becoming less common in other technical communities, it is best to simply duplicate the metaphor being used by comparable or interoperable technologies. Likewise, the IETF can show positive leadership in the technical community by setting standards without using offensive metaphors."
   - Why would you duplicate a metaphor? Why not "...substitute the term being used..."
   - What does "Likewise" mean in this context?

---

Other Considerations
 
"As we have seen," is one of those style things that I think should be avoided - Who are we? Were we paying attention?
Perhaps "As described in the preceding sections,"

---
 
Other Considerations

"like all written text," Do you mean to distinguish from other uses of language? Is it OK for me to say "blacklist" at the mic in an IETF meeting so long as I don't write it in my I-D?
 
---
 
Other Considerations

"We propose nothing more than additional care in the choice of language just as care is taken in defining standards and protocols themselves."
 
This would be a wonderful thing to say in the Introduction. It is a great way to defuse the reader's preconceptions.

---

Other Considerations

"The above two examples are not exhaustive, nor are they mere examples and require action"
 
The fact that you are "just providing two examples" was lost on me (hence some of my earlier burbling). It would be really helpful if the Introduction (and maybe even the Abstract) was very clear that:
 - our main objective is to establish the necessity for action and to propose actions
 - we do this by providing two significant examples that need attention immediately, but this is not a complete list and there will be many other terms that need to be considered.
 
That said, I think your text here is a little hard to read. Perhaps...
"The two examples provided above are not the only cases of offensive language to be avoided, and many more can be collected. However, these two examples are particularly significant and require immediate action."
 
---
 
Other Considerations

s/However, we/We/

---
 
Other Considerations
 
"That some of these metaphors are offensive leaves no excuses for their continued use." There is ambiguity in the English here that you *really* want to avoid! How about...
"If any of  these metaphors is offensive there is no excuse for its continued use."

---
 
Other Considerations

'A term like "man-in-the-middle" is not technically useful. It is not a standard term, not as clear as its alternative "on-path attacker", and should therefore be avoided'
 
Actually, I think it is way clearer than "on-path attacker" for two reasons:
1. It is so widely used as to have instant recognition
2. On-path has to be thought about because an attack may include diverting the message off its intended path
 
So, to avoid these discussions we need to focus on the issue not the debate over whether it is useful. I'd even say black-list is useful!
 
Oh, and I assume you actually mean the term "man-in-the-middle" not a term like it!
 
How about...
For example, the term "man-in-the-middle" has not be explicitly standardised, and should be replaced with an alternative such as "on-path attacker" without fear of loss of meaning.

---
 
Other Considerations

"to employ the use of metaphors or to parrot terms of art"
 
Unintentional joke?
"To parrot" is metaphorical construct that you can replace with "unthinkingly repeat"

---

Other Considerations

"We welcome additional examples of terminology that might be avoided through more awareness and thoughtfulness."

I'm not sure what your intention is here. Do you want a growing list with more examples? Creating such a list causes people to assume that items not on the list remain acceptable. And I'm not sure that more examples are necessary to explain your message.

On the other hand, categories of language to avoid may be useful. You specifically mention military language, and I think that is a good category to avoid. I also think that the use of sporting language is very problematic (touching base, striking out, not reaching first base, coming from left field, dropping the ball, scoring, getting the ball over the line, being caught out) because it is culturally based metaphor (or simile) and is problematic in three related but distinct ways:

1. It is cultural imperialism where the reader is forced to acknowledge the culture of the author.
2. The meaning may be wholly lost because the reader has no idea what the term means.
3. The meaning may be reversed because the reader perfectly understands the term, but in their culture the meaning of the term is different.

I think we should avoid the debate (per Orwell) of whether all metaphors or idioms are bad. That can be a debate for a style guide discussion, but it is not *this* debate. However, I would like to stress that the use of language that is heavily culturally based, *is* exclusionary, puts people on the outside, and makes them feel uncomfortable. Thus, without going as far as "all metaphors are bad" we might encourage authors to "consider avoiding the use of metaphors that require specific cultural knowledge or understanding."

Language is always a representation of a specific world view, and it is precisely the imposition of a specific world view that can be harmful.
 
---

Recommendations

"To summarise, we have bulleted some very concrete action points that can be taken by Editors, reviewers and Authors, both present and future."
 
I'd want to clarify that this is for work in progress not going back over the canon. So, perhaps...
 
"To summarise, we have bulleted some very concrete action points that can be taken by Editors, reviewers and Authors, both present and future as they develop and publish Internet-Drafts and new RFCs."
 
---

Recommendations

Authors bullets 1 and 2 are missing xref citations at the end of the lines.

---

Recommendations

Final Author bullet says "Consider rolling back technical hard coding of their standards implementations with the documented knowledge available online" and, supportive though I am, I have no clue what that is asking me to do! I have honestly tried to read it a dozen times and while I can guess, I can't actually extract meaning ☹

---

Recommendations

If I were an editor (oh, I am) I would want (need) a style sheet that collects all terms that have been considered, and for each whether it is acceptable, and if not what terms I should consider instead. This is pretty important, and I think you need to make that a third recommendation for the RFC Editor (it should be published, just like the style guide and the abbreviations list).

Then I would put an additional entry in the Authors list telling them to look at the style sheet

---

Recommendations

Final RFC editor bullet says "Suggest to Authors that even when referencing other specifications that have not replaced offensive terminology they could provide another term with a note that the term is original and not being suggested by the Author." I think the meaning is lost a little at the end because the "term" is not the "term" 😊
 
Perhaps...
"Suggest to Authors that even when referencing other specifications that have not replaced offensive terminology, the Authors could use another term in their document and include a note to say that they have used the new term as a replacement for the term used in the referenced document."

---
 
Additional References Not Cited Above

I suggest you call this "Further reading" since "References" has a specific meaning related to being cited.

---

Security Considerations
 
I wonder whether you can do better than this. Certainly, don't call this a "research document"! Have a think about the impact of wrong language on security and privacy. Do people who are upset by language pay less attention to the content? If the content concerns security, does that mean security may be compromised? Do we notice that security considerations often make use of exactly the language we are concerned by and that it is important that the security community picks substitute terms that convey the right meaning within that community?
 
=======

> Dear all,
>
> I hope this email finds you all very well. The current global debate
> about systemic and institutional racism has led several technology
> communities to reconsider their language and practices. Within the
> IETF this discussion has been ongoing for the last years. Mallory and
> I thought we could perhaps contribute to this discussion with the
> following draft:
>
> https://tools.ietf.org/html/draft-knodel-terminology-02
>
> We're happy to receive comments and suggestions on-list, off-list, 
> and/or as PR here:
>
> https://github.com/IRTF-HRPC/drafts/blob/master/draft-terminology.md
>
> Looking forward to discuss this here, and perhaps as well during
> IETF108. 
>
> We hope we can find community consensus on this topic.
>
> Best,
>
> Mallory and Niels

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 8 Jul 2020 15:22:44 +0200

Dear Adrian, 

Thanks a lot for your extensive review!

Dear all,

We have received quite a lot reviews, actually we have never received so many off-list reviews of a document. This might indicate both the importance as well as the sensitivity of the draft at hand. 

Based on the reviews we received, we have created a new draft which can be found here: 

https://tools.ietf.org/html/draft-knodel-terminology-03. 

If people have more input, we're happy to discuss it either before or during the meeting. Both on this list, off-list, or via pull requests and/or issues on github:

All the best,

Niels and Mallory

-- 
Niels ten Oever
Researcher and PhD Candidate - DATACTIVE Research Group - University of Amsterdam
Postdoctoral Scholar (abd) - Communications Department - Texas A&M University
Research Fellow - Centre for Internet and Human Rights - European University Viadrina
Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas

W: https://nielstenoever.net
E: [email-masked]
T: @nielstenoever
P/S/WA: +31629051853
PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3

---

From: "John Levine" <[email-masked]>
Date: 22 Jul 2020 12:37:04 -0400

In article <[email-masked]> you write:
>Thanks, Niels and Mallory, for having the strength to persevere with this important topic. I would
>like to see the IETF reach some fairly rapid resolution on the thrust of your work so that we can
>advise authors and the RPC on the way we want to use language.

Having finally gotten around to reading this draft, i think there is
some good advice combined with unhelpful and sometimes ahistoric
purported motivations.

We can stop referring to things as master and slave because we think
slavery is bad. As others have noted, western hemisphere race-based
slavery is only one variety, and vast numbers of people all over the
world became enslaved because they were the wrong religion, the wrong
side at the end of a battle, the wrong sex, or just in the wrong place
at the wrong time. 

Similarly, blacklist is a term that goes back to the 1500s and has
been used to sanction people for activities such as union organizing
or, in the mid-20th century US, accusations of political affiliation.
We can agree that blacklisting people is bad without making false
connections to race.

The gratuitous racial references have two other unfortunate effects:
one is to give an implicit free pass to people from other cultural
backgrounds, and they ignore terms that really are about race such as
the verbs "grandfather" and "redline".

Finally, the proposed list of substitutes isn't very good. Rather than
try and come up with others at this point, I would suggest people
think about what the thing they're describing is actually doing, and
the implications of the metaphors they use. Master/slave implies that
the slave has to do what the master says, which is usually what's
intended, but also that the master can sell the slave, which is not.
Look for something where the metaphor actually matches what it's
describing.

R's,
John

PS: English has a perfectly good non-gendered singular pronoun but
I've given up reminding people about it.

---

From: Bob Hinden <[email-masked]>
Date: Wed, 22 Jul 2020 14:31:32 -0700

John,

> On Jul 22, 2020, at 9:37 AM, John Levine <[email-masked]> wrote:
> 

I agree with you, I think we should stop using terminology like master/slave, white/black list, etc, in IETF specifications.

Also, that the current document needs a lot of work before it could go forward.

To Pete’s email, where should this work take place?

Bob

> Gendispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gendispatch

---

From: "Pete Resnick" <[email-masked]>
Date: Wed, 22 Jul 2020 21:19:11 -0500

> To Pete’s email, where should this work take place?

See my other response, but this is part of the question the WG is meant 
to answer. Do we think we need a WG or BOF to work on this? Then we're 
probably going to suggest discussing on a new mailing list. If we think 
this belongs somewhere else, e.g., I could imagine that we decide that 
it should be part of the RFC Editor's responsibility, then we could ask 
the IETF Chair or LLC to take up the work. But we've got a whole menu of 
options. I'm happy to start talking about that now in addition to at our 
meeting next week.

pr
-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 23 Jul 2020 13:17:18 +0000

> I'm happy to start talking about that now in addition to at our meeting next week.

What do you think about asking the IAB to start an inclusivity program?

---

From: Dan Harkins <[email-masked]>
Date: Thu, 23 Jul 2020 09:09:08 -0700

Hi Pete,

On 7/22/20 7:19 PM, Pete Resnick wrote:
> See my other response, but this is part of the question the WG is 
> meant to answer. Do we think we need a WG or BOF to work on this? Then 
> we're probably going to suggest discussing on a new mailing list. If 
> we think this belongs somewhere else, e.g., I could imagine that we 
> decide that it should be part of the RFC Editor's responsibility, then 
> we could ask the IETF Chair or LLC to take up the work. But we've got 
> a whole menu of options. I'm happy to start talking about that now in 
> addition to at our meeting next week.

   Well I hope one of the choices on the menu is rejection of the new 
work. That
was mentioned as a possibility laid out by the charter in your previous 
email.
And I hope I'm not out-of-line assuming that your offer of beginning 
talking about
the menu of options for the terminology draft includes rejection. So 
assuming....

   In its current form I think the draft should be rejected. The racial 
references
are unfounded and gratuitous. Their presence in the draft is divisive. 
The attack
on some random person, by name!, for a comment on a blog in 2008 is 
extremely
unprofessional (12 years is a long time, Barack Obama was saying that 
"marriage
is between a man and a woman" back in 2008, the kind of thing that would 
get you
drummed out of polite society in 2020). We don't need to bring cancel 
culture
into the IETF.

   I did recommend some changes to the draft that I think would make it less
objectionable-- remove all the accusations of racism and the discussion 
of race
and language, rewrite the draft to be more about getting rid of bad 
metaphors
which may not have universal understanding-- but that would also remove the
potential for virtue signaling and remove the need for having purges of 
bad words
that represent bad think.

   So I guess from my perspective it depends on what the authors want. 
Do they want
to establish the word police to hunt out bad think (and bad thinkers!) 
or do they
just want clearer and more descriptive metaphors used in RFCs?

   regards,

   Dan.

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Thu, 23 Jul 2020 10:27:27 -0700 (PDT)

> What do you think about asking the IAB to start an inclusivity program?

I think the idea is OK, but the what you called it is the wrong tone,
inclusivity is not what should be done here, what should be done is the
reduction of exclusivity.

Inclusivity is an unbounded problem, reduction of exclusivity is fairly
well bounded.

-- 
Rod Grimes                                                 [email-masked]

---

From: Mallory Knodel <[email-masked]>
Date: Thu, 23 Jul 2020 13:36:46 -0400

> Inclusivity is an unbounded problem, reduction of exclusivity is fairly

I'm heartened to respond to such a suggestion; thanks for making it. I 
would offer the knowledge that there are many such programmes in 
existence and true experts on whom we could rely for best practice. Many 
of those experts would tell you that inclusivity and reducing 
exclusivity go hand in hand. Lowering barriers to entry is only one part 
of the feat-- equality in representation is a bootstrap.

I'd like to continue thinking of innovative ways to dispatch this work 
further.

-Mallory

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Thu, 23 Jul 2020 10:40:03 -0700 (PDT)

Hello Dan,
	Since you have brought up what I consider an excellent
path forward twice now, I want to chime in with a voice of support
for your tactic on what might be the best path forward for this
type of work.

	Though I must state the draft is better than most
things I have read on this subject, it still fells a bit
wrong from my perspective as well.  You summarize this fairly
well in your feedback.

	I do like the idea of addressing the poor quality
metaphore problem is a sound path that would benifit the
quality of the RFC documents.

Regards,
Rod Grimes

>  ? Hi Pete,
> >> To Pete?s email, where should this work take place?
> >
>  ? Well I hope one of the choices on the menu is rejection of the new 
> work. That
>  ? In its current form I think the draft should be rejected. The racial 
> references

Agreed, if it was up for WG adoption it should be rejected in its
present form based on your assertions.

> 
>  ? I did recommend some changes to the draft that I think would make it less

+1 again, the key being "getting rid of bad metaphors."

> 
>  ? So I guess from my perspective it depends on what the authors want. 
> Do they want
>  ? regards,
>  ? Dan.

Regards,

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 23 Jul 2020 15:00:34 -0400

> On Jul 22, 2020, at 10:19 PM, Pete Resnick <[email-masked]> wrote:
> 
> See my other response, but this is part of the question the WG is meant to answer. Do we think we need a WG or BOF to work on this? Then we're probably going to suggest discussing on a new mailing list. If we think this belongs somewhere else, e.g., I could imagine that we decide that it should be part of the RFC Editor's responsibility, then we could ask the IETF Chair or LLC to take up the work. But we've got a whole menu of options.

In addition to the ideas I’ve seen discussed on the list thus far (in the draft, updates to the RFC Style Guide, changes to the idnits tool), I’ve been wondering whether writing up some guidance for Gen-ART reviewers could also be part of the mix here. This could have a simple focus on checking for clear, descriptive metaphors, or it could be more detailed. In any event since the directorate reviews every document before publication that might be an additional tool to consider.

I would also note that since our collective understanding of the impact of language evolves over time, it might be useful to think about the line between what might get memorialized in an RFC (say, a broader statement of policy or principle that doesn’t change often) versus what might get documented in a form that could be more detailed and easier to update like the I-D checklist [1] (which is fairly out of date but technically easier to update than an RFC) or an IESG statement.

Alissa

[1] https://www.ietf.org/standards/ids/guidelines/

---

From: "Pete Resnick" <[email-masked]>
Date: Thu, 23 Jul 2020 14:57:23 -0500

On 23 Jul 2020, at 11:09, Dan Harkins wrote:

>> meant to answer. Do we think we need a WG or BOF to work on this? 
>> Then we're probably going to suggest discussing on a new mailing 
>> list. If we think this belongs somewhere else, e.g., I could imagine 
>> that we decide that it should be part of the RFC Editor's 
>> responsibility, then we could ask the IETF Chair or LLC to take up 
>> the work. But we've got a whole menu of options. I'm happy to start 
>> talking about that now in addition to at our meeting next week.
>
> work.

Absolutely, and perfectly fine to discuss such a possibility here on the 
list in addition to at the session next week.

>   In its current form I think the draft should be rejected.

That's sort of a multipart answer to the question, and I think you get 
at this elsewhere in your message: If the authors somehow insisted that 
the current approach to the draft is the one and only way they're 
willing to work on it, rejecting it would be perfectly appropriate. But 
most authors are more reasonable than that (and I take Niels and Mallory 
to be pretty reasonable), so the better way to construct that answer is, 
"With changes A, B and C, I would deploy it to X, with changes 1, 2, and 
3, I might deploy it to Y, and I think it would be most useful if we 
aimed toward changes A, B, and C". Of course, you might also say, "I 
don't think anything like this is worth doing at all, even with changing 
the form of the document, so we should just reject it." Make it clear to 
folks which direction you are leaning.

> just want clearer and more descriptive metaphors used in RFCs?

Those are, of course, not the only two choices. It might be reasonable 
to propose a document to remind people that some metaphors can be 
obnoxious, even if they are meant innocuously or humorously, and that 
people should keep an eye out for that possibility, without making the 
document contain a list of "bad words" to be avoided. You may or may not 
be on board with such a document, but best not to artificially set the 
list of choices with straw men.

pr

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 24 Jul 2020 15:57:26 +1200

> I’ve been wondering whether writing up some guidance for Gen-ART reviewers could also be part of the mix here. This could have a simple focus on checking for clear, descriptive metaphors, or it could be more detailed. In any event since the directorate reviews every document before publication that might be an additional tool to consider.

Being a Gen-ART reviewer, I found myself wondering how much extra work that would be. Probably not much, in reality. But just for fun I did a quick analysis of one of my folders that contains about 570 drafts.

There are roughly 87 instances of "master", 37 instances of "slave", and about 88 instances of the string "black"**. The latter occurs at least 21 times as part of "blacklist"|"black list"|"black-list", and at least 39 times as part of "blackhole"|"black hole"|"black-hole".

** after removing names of people and ignoring draft-knodel itself.

Regards
   Brian Carpenter