Skip to main content

Avoiding Exclusionary Language in RFCs

Document Type Expired Internet-Draft (individual)
Expired & archived
Author Keith Moore
Last updated 2021-03-08 (Latest revision 2020-08-26)
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


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.


Keith Moore

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)