Network Working Group M. Knodel
Internet-Draft Center for Democracy & Technology
Intended status: Informational N. ten Oever
Expires: 13 August 2022 University of Amsterdam
9 February 2022
Terminology, Power, and Exclusionary Language in Internet-Drafts and
RFCs
draft-knodel-terminology-09
Abstract
This document argues for more inclusive language conventions
sometimes used by RFC authors and the RFC Production Centre in
Internet-Drafts that are work in progress, and in new RFCs that may
be published in any of the RFC series, in order to foster greater
knowledge transfer and improve diversity of participation in the
IETF.
This document represents the opinion of the authors and does not have
IETF consensus.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 August 2022.
Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Knodel & ten Oever Expires 13 August 2022 [Page 1]
Internet-Draft Terminology February 2022
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology and Power in Internet-Drafts and RFCs . . . . . . 3
2.1. Master-Slave . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Blacklist-Whitelist . . . . . . . . . . . . . . . . . . . 6
2.3. Other Considerations . . . . . . . . . . . . . . . . . . 7
3. Summary of Recommendations . . . . . . . . . . . . . . . . . 8
4. Further Reading . . . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Informative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
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 RFCs,
Internet-Drafts (I-Ds), 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.
We propose nothing more than care in the choice of language just as
care is taken in defining standards and protocols themselves.
The point of the piece is to lift up the voices of those who choose
not to engage because of harmful dynamics such as exclusionary
language.
Knodel & ten Oever Expires 13 August 2022 [Page 2]
Internet-Draft Terminology February 2022
This document presents arguments for why exclusionary terms should be
avoided in Internet-Drafts and RFCs and, as an exercise, describes
the problems introduced by some specific terms and why their proposed
alternatives improve technical documentation. The example terms
discussed in this document are "master-slave" and "whitelist-
blacklist". There is a section on additional considerations and
general action points to address future RFCs and I-Ds. Lastly, a
summary of recommendations is presented.
2. Terminology and Power in Internet-Drafts and RFCs
This analysis is presented as the authors' commentary on the IETF
process and does not represent the opinion of the IETF.
According to the work of Heather Brodie Graves from 1993, "One goal
of the application of rhetorical theory in the technical
communication classroom is to assess the appropriateness of
particular terms and to evaluate whether these terms will facilitate
or hinder the readers' understanding of the technical material"
[BrodieGravesGraves]. This implies that in order to effectively
communicate the content of I-Ds and RFCs to all readers, it is
important for Authors to consider the kinds of terms or language
conventions that may inadvertently get in the way of effective
communication. She continues, "Complex and subtle configurations of
sexist, racist, or ethnocentric language use in technical documents
can derail or interfere with readers' ability and desire to
comprehend and follow important information."
Indeed, problems of language are problems of everyday speech. Racist
and sexist language is rampant and similarly counter-productive in
other sectors, notably social work [Burgest]. The terms "master-
slave" (treated in detail below) are present in other realms of
technology, notably, "Automotive clutch and brake systems, clocks,
flip-flop circuits, computer drives, and radio transmitters"
[Eglash].
However, it is not too late for these terms to be replaced with
alternative metaphors that are more accurate, clearer, less
distracting, and that do not offend their readers. Language matters
and metaphors matter. Indeed, metaphors can be incredibly useful
devices to make more human the complex technical concepts presented
in RFCs. Metaphors should not be avoided, but rather taken
seriously. Renowned linguist George Lakoff argued in 1980 that the
ubiquitous use of metaphors in our everyday speech indicates a
fundamental instinct to "structure our most basic understandings of
experience" [Lakoff]. Metaphors structure relationships, and they
frame possibilities and impossibilities [Wyatt].
Knodel & ten Oever Expires 13 August 2022 [Page 3]
Internet-Draft Terminology February 2022
The role of language is to describe the world and maintain social
relationships. The way in which the world, people, and institutions
are described provides a particular ordering to the world. This
ordering function of language is what makes it a potential instrument
for power and control. The understanding of power in relation to
language, as used in this document, is the way in which language
reflects, influences, and shapes social relations.
Like Graves, this document recognises the monumental challenge of
addressing linguistics and power, and attempts to promote awareness
that may lead to eventual wide-spread change and suggests first steps
for actions that may remedy the inadvertent use of undesirable terms.
To that end, the list below is a tersely written set of IETF-specific
arguments as to why the RFC Editor should be encouraged to remedy
issues with respect to exclusionary language and metaphors:
1. The RFC series is intended to remain online in perpetuity.
Societal attitudes to offensive and exclusionary language shift
over time in the direction of more empathy, not less.
2. That exclusionary terms in RFCs are largely hidden from the wider
public, or read only by engineers, is no excuse to ignore social-
level reactions to the terms. If the terms would be a poor
choice for user-facing application features, the terms should be
avoided in technical documentation and specifications, too.
3. At the time of writing, the digital technology community has a
problem with monoculture [RFC7704] [Cath]. And because the lack
of diversity of the technical community is a problem, a key
strategy to breaking monoculture is to ensure that technical
documentation is addressed to a wider audience and more readers.
4. The technical community already includes members who take offense
to these terms. Eradicating the use of exclusionary terminology
in technology recognises the presence of and acknowledges the
requests from black and brown engineers and from women and
gender-non-conforming engineers to avoid the use of exclusionary
terminology [Wired] [Seele]. RFCs and I-Ds are some of the
primary technical specifications in the Internet and should
follow this principle.
This document does not try to prescribe terminology shifts for any
and all language that could be deemed exclusionary. Instead we
illustrate an overall approach through the following two most
eggregious examples of specific term pairs "master-slave" and "white-
blacklist" and the rationale for the use of suggested alternatives.
Suggested actions for handling additional considerations are
presented in a subsequent section.
Knodel & ten Oever Expires 13 August 2022 [Page 4]
Internet-Draft Terminology February 2022
2.1. Master-Slave
Master-slave is an offensive and exclusionary metaphor that will and
should never become fully detached from history. Aside from being
unprofessional and exclusionary it stifled the participation of
students whom Eglash interviewed for his research. He asks: "If the
master-slave metaphor affected these tough-minded engineers who had
the gumption to make it through a technical career back in the days
when they may have been the only black persons in their classes, what
impact might it have on black students who are debating whether or
not to enter science and technology careers at all?" [Eglash]
Aside from the arguably most important reason outlined above, these
terms are becoming less used and therefore increasingly less
compatible as more communities move away from their use (e.g.
[NIST], [Python], [Drupal], [Github] and [Django] ). The usage of
'master' and 'slave' in hardware and software has been halted by the
Los Angeles County Office of Affirmative Action, the Django
community, the Python community and several other programming
languages. This was done because the language is offensive and hurts
people in the community [Django2]. Root operator Internet Systems
Consortium recognised that the terms 'master' and 'slave' are very
value-laden and responded to multiple requests from users by offering
an inoffensive alternative [ISC].
In addition to being inappropriate, the master-slave metaphor is both
technically and historically inaccurate. For instance, in DNS the
'slave' is able to refuse zone transfers on the ground that they are
malformed. The metaphor is incorrect historically given the most
recent centuries during which "the role of the master was to abdicate
and the role of the slave was to revolt" [McClelland]. Yet "slavery"
is not just a historic term: whereas freedom from slavery is a human-
rights issue [UDHR], slavery continues to exist in the present day
[Wikipedia]. Furthermore, this term set wasn't revived until
recently, after WWII, and after many of the technologies that adopted
it were already in use with different terminology [Eglash].
Ultimately master-slave is a poor choice since:
1. it is being used less frequently already in a variety of
applications,
2. it has perceived exclusionary effects,
3. concerned members of the technical community have requested that
its use be ceased.
Knodel & ten Oever Expires 13 August 2022 [Page 5]
Internet-Draft Terminology February 2022
Eglash's research calls into question the accuracy of the master-
slave metaphor. To find alternatives to master-slave, one can look
to many existing implementations of technology. There are also many
other relationships that can be used as metaphors. An alternative
should be chosen based on the pairing that is most clear in context:
* Primary-secondary based on authority. See for example [RFC8499].
* Primary-replica based originality.
* Active-standby based on state.
* Writer-reader based on function.
2.2. Blacklist-Whitelist
The metaphorical use of white-black to connote good-evil is
exclusive. While master-slave might seem like a more egregious
example of racism, white-black is arguably worse because it is more
pervasive and therefore more insidious. While recent headlines have
decried the technical community's use of master-slave, there is far
less discussion about white-black despite its importance. There is
even a name for this pervasive language pitfall: the association of
white with good and black with evil is known as the "bad is black
effect" [Grewal].
Indeed, there is an entire book on the subject, written by renowned
authority on race, Frantz Fanon. In his book "Black Skin, White
Masks," Fanon makes several persuasive arguments that standard
language encodes subconscious in-group, out-group preferences
[Fanon].
In the case of blacklist-whitelist in the technical documentation of
I-Ds and RFCs, it is entirely a term of art and an arbitrary
metaphorical construct with no technical merit. There are scientific
uses of black that are related to light - black holes are black
because light cannot escape them. Blacklist-whitelist is not a
metaphor for lightness or darkness, it is a good-evil metaphor and
therefore this trope has significant impact on how people are seen
and treated. As we've seen with metaphors, its use is pervasive and,
though not necessarily conscious, perceptions do get promulgated
through culture and repetition.
Knodel & ten Oever Expires 13 August 2022 [Page 6]
Internet-Draft Terminology February 2022
As with master-slave, we save our technical argument for last,
referencing and presenting first the reasons for the use of non-
offensive, alternative terminology for the sake of our humanity.
Indeed, our technical argument is succinct: Why use a metaphor when a
direct description is both succinct and clear? There can be
absolutely no ambiguity if one uses the terms, as suggested below,
allow-block rather than white-black.
There are alternatives to this terminology set that vastly improve
clarity because they are not even metaphors, they're descriptions.
The alternatives proposed here say exactly what they mean.
* Accept-list and Drop-list for threat signaling. See for example
[RFC8612], [RFC9132], and [RFC8783]).
* Blocklist-allowlist, deny-allow, exempt-allowlist or block-permit
for permissions.
2.3. Other Considerations
As described in the preceding sections, the language used in
technical documentation, like all written text, creates and
reinforces expectations and stereotypes. We propose nothing more
than additional care in the choice of language just as care is taken
in defining standards and protocols themselves. The two examples
provided above are not the only cases of exclusionary language to be
avoided, and many more can be collected. We use this section to
broaden the context of other offensive and exclusionary terminologies
to encompass additional concerns, why spotting and eradicating
problematic terminologies is a valid endeavour for authors and
editors of technical documentation and how this might be
systematised.
There are many other metaphors present in technical documentation
that are "terms of art" but that have no technical basis whatsoever.
If any of these metaphors is offensive there is no excuse for its
continued use. 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. When presented
with the opportunity to employ the use of metaphors or to
unthinkingly repeat terms of art that connote gender or race, Authors
should simply find a better way to explain themselves. A fun read on
the politics of colloquial speech by George Orwell should dissuade
any Author from using tired explanatory metaphors [Orwell].
The unnecessary use of gendered pronouns is a sexist practise that is
common but easy to spot and replace. Without a neutral singular
pronoun, "he" is assumed as the default singular pronoun when the
Knodel & ten Oever Expires 13 August 2022 [Page 7]
Internet-Draft Terminology February 2022
gender of the person is unknown or ambiguous. However, that has
changed, and it is now widely accepted that "they" can be used as a
neutral singular pronoun. Since it is unlikely that all implementers
and infrastructure operators are of any particular gender, "he"
should never be used to refer to a person in I-Ds and RFCs. An
Author who uses male examples sets male-ness as a standard.
Besides race and gender, our world is full of metaphors rooted in
oppression, ableism, and colonialism. Militarised metaphors are also
a pervasive problem in language, perhaps even more so in technical
communities because of the historical and actual relationship between
technology and war. Authors of RFCs need to be especially on their
guard against all manner of metaphors that may carry unwanted
overtones.
While it is not our intention to be exhaustive we hope to have made a
persuasive case for authors and editors to pay attention to the finer
details of metaphor, and the ways power is replicated in technical
documentation unless detailed attention is paid. The example terms
above "master-slave" and "blacklist-whitelist" are already less
common. If the IETF community has learned anything from the debate
over the use of these terms, and this document, it is that language
matters to us deeply as members of society and as engineers. And
because language, and society, change over time, we must approach
future concerns with some degree of dispassion when the arguments
presented in the first section can be clearly applied.
There is harm in protracted discussion about the validity of the
experience of IETF participants with exclusionary terminology because
it invalidates this people's experiences. Behavior that, some of
which labeled IESG as racist and disrepectful and therefore removed
[White1] [White2] surfaced in the community as a result of this
larger debate among technologists pushed away participants and
observers [Conger]. This illustrates the need to, as Graves is cited
above as saying, continue to raise awareness within our community for
eventual, lasting change on the continued front of struggle against
the racists amongst us. Yet we recommend a living stylesheet, rather
than repeated RFCs, be used as a mechanism for monitoring
exclusionary language in IETF documents [inclusiveterminology].
It is there that we welcome additional examples of terminology that
might be avoided through more awareness and thoughtfulness.
3. Summary of Recommendations
To summarise, we have listed some 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.
Knodel & ten Oever Expires 13 August 2022 [Page 8]
Internet-Draft Terminology February 2022
The authors think that document authors should:
* Replace and avoid the exclusionary terms "master-slave" and
"blacklist-whitelist" with more accurate alternatives.
* Read and reflect upon the repository of exclusionary terminology
maintained by the community [inclusiveterminology].
* As the IESG has recommended [IESG], follow the NIST guidance on
the use of inclusive language in standards [NIST0].
* Reflect on their use of metaphors generally.
* Consider changing existing exclusionary language in current
(reference) implementations [socketwench].
* Consult the RFC Editor Style Guide.
The authors think that the RFC editor should:
* Offer alternatives for exclusionary terminology as an important
act of correcting larger editorial issues and clarifying technical
concepts.
* Consult the IETF community and other sources to build and maintain
a style sheet that collects reconsidered terminology relevant to
the IETF.
* 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.
4. Further Reading
For more information on this topic we suggest reading:
Ford, Heather., Wajcman, Judy. 2017. "'Anyone can edit', not
everyone does: Wikipedia and the gender gap" Social Studies of
Science. ISSN 0306-3127
Grant, Barbara M. 2008. "Master-slave dialogues in humanities
supervision" Arts and Humanities in Higher Education, Volume: 7
issue: 1, page(s): 9-27 https://doi.org/10.1177/1474022207084880
Miller, Carolyn, R. 1979. "A Humanistic Rationale for Technical
Writing" College English, Vol. 40, No. 6, pp. 610-617
Knodel & ten Oever Expires 13 August 2022 [Page 9]
Internet-Draft Terminology February 2022
5. Security Considerations
Security is dependent on a wide range of actors that are implementing
technical documentation. Therefore it is crucial that language is
clear, and understood by all that need to implement this
documentation. Correct and inclusive language is therefore conducive
for secure implementations of technical documentation.
Changing terminology that is common in use can be leveraged as
security risk because it may lead people to misunderstand what is
being talked about. It is therefore recommended that when language
is changed because of the reasons described in this document, it
should be documented as such.
6. IANA Considerations
This document has no actions for IANA.
7. Informative References
[RFC7322] Flanagan, H. and S. Ginoza, "RFC Style Guide", RFC 7322,
DOI 10.17487/RFC7322, September 2014,
<https://www.rfc-editor.org/info/rfc7322>.
[RFC7704] Crocker, D. and N. Clark, "An IETF with Much Diversity and
Professional Conduct", RFC 7704, DOI 10.17487/RFC7704,
November 2015, <https://www.rfc-editor.org/info/rfc7704>.
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC9132] Boucadair, M., Ed., Shallow, J., and T. Reddy.K,
"Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Specification", RFC 9132,
DOI 10.17487/RFC9132, September 2021,
<https://www.rfc-editor.org/info/rfc9132>.
[RFC8783] Boucadair, M., Ed. and T. Reddy.K, Ed., "Distributed
Denial-of-Service Open Threat Signaling (DOTS) Data
Channel Specification", RFC 8783, DOI 10.17487/RFC8783,
May 2020, <https://www.rfc-editor.org/info/rfc8783>.
[RFC8612] Mortensen, A., Reddy, T., and R. Moskowitz, "DDoS Open
Threat Signaling (DOTS) Requirements", RFC 8612,
DOI 10.17487/RFC8612, May 2019,
<https://www.rfc-editor.org/info/rfc8612>.
Knodel & ten Oever Expires 13 August 2022 [Page 10]
Internet-Draft Terminology February 2022
[Burgest] Burgest, David R., "Racism in Everyday Speech and Social
Work Jargon.", Social Work, vol. 18, no. 4, 1973, pp.
20-25 , 1973, <www.jstor.org/stable/23711113.>.
[Eglash] Ron Eglash, ., "Broken Metaphor: The Master-Slave Analogy
in Technical Literature.", Technology and Culture, vol. 48
no. 2, 2007, pp. 360-369. , 2007,
<https://doi.org/10.1353/tech.2007.0066
https://www.researchgate.net/
publication/236752849_Broken_Metaphor_The_Master-
Slave_Analogy_in_Technical_Literature>.
[BrodieGravesGraves]
Heather Brodie Graves, . and . Roger Graves, "Masters,
slaves, and infant mortality: Language challenges for
technical editing", Technical Communication Quarterly,
7:4, 389-414 , 1998,
<https://doi.org/10.1080/10572259809364639>.
[Wyatt] Sally Wyatt, ., "Danger! Metaphors at Work in Economics,
Geophysiology, and the Internet", Science, Technology, and
Human Values, Volume: 29 issue: 2, page(s): 242-261 ,
2004,
<https://journals.sagepub.com/doi/10.1177/0162243903261947
https://www.exeter.ac.uk/media/universityofexeter/internat
ionalexeter/documents/iss/Wyatt_danger-metaphors_(3).pdf>.
[Lakoff] George Lakoff, . and . Mark Johnson, "Metaphors We Live
By", U of Chicago P, 1980. , n.d..
[Orwell] George Orwell, ., "Politics and the English Language",
1946,
<https://www.orwell.ru/library/essays/politics/english/
e_polit/>.
[McClelland]
McClelland, J., "We need better metaphors", 2011,
<https://current.workingdirectory.net/posts/2011/master-
slave>.
[UDHR] United Nations General Assembly, "The Universal
Declaration of Human Rights", 1948,
<http://www.un.org/en/documents/udhr/>.
[Fanon] Fanon, F., "Black skin, white masks", 1952.
Knodel & ten Oever Expires 13 August 2022 [Page 11]
Internet-Draft Terminology February 2022
[Python] Daniel Oberhaus, ., "'master-slave' Terminology Was
Removed from Python Programming Language", 2018,
<https://motherboard.vice.com/en_us/article/8x7akv/
masterslave-terminology-was-removed-from-python-
programming-language>.
[Django] fcurella, ., "#22667 replaced occurrences of master-slave
terminology with leader/follower #2692", 2014,
<https://github.com/django/django/pull/2692>.
[Django2] lynncyrin, ., "comment on #22667 replaced occurrences of
master-slave terminology with leader/follower #2692",
2014, <https://github.com/django/django/
pull/2692#issuecomment-44221563>.
[Wikipedia]
Wikipedia, "Slavery in the 21st century", 2018,
<https://en.wikipedia.org/wiki/
Talk:Slavery_in_the_21st_century>.
[Drupal] Xano, ., "Replace 'master-slave' terminology with
'primary/replica'", 2014,
<https://www.drupal.org/project/drupal/issues/2275877>.
[Grewal] Grewal, D., "The 'Bad Is Black' Effect", 2017,
<https://www.scientificamerican.com/article/the-bad-is-
black-effect/>.
[socketwench]
socketwench, ., "Even in tech, words matter", 2018,
<https://deninet.com/blog/2018/09/09/even-tech-words-
matter>.
[ISC] Internet Systems Consortium, ., "@ISCdotORG reply tweet",
2017,
<https://twitter.com/ISCdotORG/status/943152507211071489>.
[Github] Kevin Truong, . and VICE, "Github to Remove 'Master/Slave'
Terminology From its Platform", June 2020,
<https://www.vice.com/en_us/article/k7qbyv/github-to-
remove-masterslave-terminology-from-its-platform>.
[NIST] Eric Geller, . and Politico, "Agency to end use of
technology terms such as 'master' and 'slave' over racist
associations", June 2020,
<https://www.politico.com/news/2020/06/25/agency-ends-use-
technology-terms-racist-associations-339880>.
Knodel & ten Oever Expires 13 August 2022 [Page 12]
Internet-Draft Terminology February 2022
[inclusiveterminology]
IETF, "Inclusive terminology in IETF Documents", August
2020, <https://github.com/ietf/terminology>.
[Cath] Corinne Cath, ., "The Technology We Choose to Create:
Human Rights Advocacy in the Internet Engineering Task
Force", Telecommunications Policy 45, no. 6 (July 1,
2021): 102144. , 2021,
<https://doi.org/10.1016/j.telpol.2021.102144.>.
[Wired] Elizabeth Landau, . and Wired, "Tech Confronts Its Use of
the Labels 'Master' and 'Slave'", 2020,
<https://www.wired.com/story/tech-confronts-use-labels-
master-slave/>.
[Seele] Mike Seele, ., "Striking Out Racist Terminology in
Engineering", 2020, <https://www.bu.edu/articles/2020/
striking-out-racist-terminology-in-engineering/>.
[Conger] Kate Conger, . and New York Times, "'Master,' 'Slave' and
the Fight Over Offensive Terms in Computing", 2021,
<https://www.nytimes.com/2021/04/13/technology/racist-
computer-engineering-terms-ietf.html>.
[IESG] Internet Engineering Steering Group, "IESG Statement on
Inclusive Language", 2021,
<https://www.ietf.org/about/groups/iesg/statements/on-
inclusive-language/>.
[NIST0] National Institute of Standards and Technology, "Guidance
for NIST Staff on Using Inclusive Language in Documentary
Standards", 2021, <https://doi.org/10.6028/NIST.IR.8366>.
[White1] Les White, ., "TLS Preferred Pronouns", 2021,
<https://datatracker.ietf.org/doc/html/draft-les-white-
tls-preferred-pronouns-00>.
[White2] Les White, ., "Intersectional Dots", 2021,
<https://datatracker.ietf.org/doc/html/draft-les-white-
intersectional-dots-00>.
Authors' Addresses
Mallory Knodel
Center for Democracy & Technology
Email: mknodel@cdt.org
Knodel & ten Oever Expires 13 August 2022 [Page 13]
Internet-Draft Terminology February 2022
Niels ten Oever
University of Amsterdam
Email: mail@nielstenoever.net
Knodel & ten Oever Expires 13 August 2022 [Page 14]