Re: [Gendispatch] draft-knodel-terminology-03

[Niels ten Oever <[e-mail]>]

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:

https://github.com/IRTF-HRPC/drafts/blob/master/draft-terminology.md

All the best,

Niels and Mallory




On 7/3/20 12:30 PM, Adrian Farrel wrote:
> 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
> 

-- 
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: [e-mail]
T: @nielstenoever
P/S/WA: [phone]
PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3