Subject: [Terminology] Guidance for NIST Staff on Using Inclusive Language in Documentary Standards (NISTIR 8366)

From: Nick Doty <[email-masked]>
Date: Thu, 29 Apr 2021 15:45:20 -0400

Today, NIST has published this Internal Report on "using inclusive
language" publicly, in part because it may be useful to other standards
groups interested in clarity and inclusiveness of terminology.

Blog post/announcement:
https://www.nist.gov/news-events/news/2021/04/nists-inclusive-language-guidance-aims-clarity-standards-publications

NISTIR 8366:
https://doi.org/10.6028/NIST.IR.8366

I think both the blog post and the report itself do a good job of
describing the particular goals, including some examples (but not
especially long lists), and pointing to other resources that might be
useful for writing standards that are clear and respectful to a wide range
of readers.

Hope this helps,
Nick

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Apr 2021 16:17:29 -0400

On 4/29/21 3:45 PM, Nick Doty wrote:
> language" publicly, in part because it may be useful to other 
> standards groups interested in clarity and inclusiveness of terminology.
>
> Blog post/announcement:
> <https://www.nist.gov/news-events/news/2021/04/nists-inclusive-language-guidance-aims-clarity-standards-publications>
>
> NISTIR 8366:
> <https://doi.org/10.6028/NIST.IR.8366>
>
> useful for writing standards that are clear and respectful to a wide 
> range of readers.
>
> Hope this helps,
> Nick

I could _almost_ support just using this document, especially if it 
would get IETF out of the business of trying to write its own.   Then we 
could all just get back to work.

A couple of its examples are problematic, and are actually good examples 
of why such guidelines can do harm to the readability of technical 
documents.

One that stood out is recommending use of plug/socket rather than 
male/female connectors.   Even though the gender analogy is cringeworthy 
(along with the term androgynous connector), the terms male and female 
as applied to connectors are actually MUCH more precise, because there 
are many kinds of connectors for which the male and female ends are much 
more obvious than the plug vs. socket designations.   (There are 
exceptions, like "reverse polarity" SMA and TNC connectors for which the 
female connector is the one with the inner pin, but mostly this 
convention works well and it's hard to replace.   plug/socket don't do it.)

Another example is recommending against use of "totem pole" as a 
priority scheme, but "totem pole" is actually the established term of 
art for a kind of electrical circuit, and again not easily replaced.

Neither of these would probably affect IETF very much though since we're 
not generally in the business of specifying connectors or electrical 
circuits.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Apr 2021 08:50:35 +1200

> could all just get back to work.

Yes. The IESG could suggest to the RFC Editor team to add an informative
reference to the NIST document to the style guide, and remind the IETF
that Internet-Drafts should aim to adhere to the RFC style guide,
and we're done.

(Clearly NIST is not international in scope, and the IETF is, but since
our shared working language is more or less American English, it seems
reasonable.)

---

From: Christian Huitema <[email-masked]>
Date: Thu, 29 Apr 2021 14:10:11 -0700

> our shared working language is more or less American English, it seems

+1. One of the best ways to make progress quickly.

-- Christian Huitema

---

From: "John Levine" <[email-masked]>
Date: 29 Apr 2021 17:25:41 -0400

>+1. One of the best ways to make progress quickly.

Sounds good to me.

The IETF has all sorts of problems with our long-standing culture of, ah, lack of consideration.
Terminology is about 1% of the problem so if this lets us get it out of the way so we can think about
working on the other 99%, all the better.

R's,
John

---

From: Andrew Campling <[email-masked]>
Date: Thu, 29 Apr 2021 21:30:31 +0000

On 29 April 2021 21:51, Brian E Carpenter <[email-masked]> wrote:

> On 29 April 2021 21:17, Keith Moore <[email-masked]> wrote:
>> would get IETF out of the business of trying to write its own.   Then 
>> we could all just get back to work.

> Yes. The IESG could suggest to the RFC Editor team to add an informative reference to the NIST document to the style guide, and remind the IETF that Internet-Drafts should aim to adhere to the RFC style guide, and we're done.

> (Clearly NIST is not international in scope, and the IETF is, but since our shared working language is more or less American English, it seems
reasonable.)

+1 - even though the NIST document (https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8366.pdf) is clearly US-centric, section 4.1 would appear to me to address the issues that have surfaced in the discussions on the list.  

Andrew

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Apr 2021 20:50:33 -0400

> that Internet-Drafts should aim to adhere to the RFC style guide,

I think I'd be ok, maybe even happy, with that result.   As long as the 
reference were informative.

Presumably the RFC Editor would also be able to add other references 
that they deemed appropriate and useful for RFCs.

Keith

---

From: [email-masked]
Date: Thu, 29 Apr 2021 21:00:08 -0400

Though relying on eternal content to serve also as internal oontent 
would require all the apparatus of constantly checking for 
modifications.

On 29.04.2021 20:50, Keith Moore wrote:
> I think I'd be ok, maybe even happy, with that result.   As long as
> the reference were informative.
>

---

From: "Bron Gondwana" <[email-masked]>
Date: Fri, 30 Apr 2021 14:38:58 +1000

Relying on external content is always going to be a thing, given that we're adapting to a changing world with this work.

If there's anything approaching consensus on "reference NIST and be done with it" then I'm all in favour of dropping my draft and getting my focus back to helping my working groups progress their work!  I'd be well happy for the TERM working group to never form and for us to take our energy elsewhere.

Cheers,

Bron.

On Fri, Apr 30, 2021, at 11:00, [email-masked] <mailto:reynolds%40cogitage.pairsite.com> wrote:
> -- 
> Terminology mailing list
> [email-masked] <mailto:Terminology%40ietf.org>
> https://www.ietf.org/mailman/listinfo/terminology
> 

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 30 Apr 2021 10:04:09 +0200

> +1. One of the best ways to make progress quickly.

I would support this as well - small suggestion: the easier way to it may be linking in the style guide to:

https://github.com/ietf/terminology/

and adding the NIST as a reference there. That way we would have some version control and could iterate when needed. 

All the best,

Niels

-- 
Niels ten Oever, PhD
Postdoctoral Researcher - Media Studies Department - University of Amsterdam
Research Fellow - Centre for Internet and Human Rights - European University Viadrina
Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas
Affiliated Factulty - Digital Democracy Insitute - Simon Fraser University

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

Read my latest article on Internet infrastructure governance in New Media & Society here: https://journals.sagepub.com/doi/full/10.1177/1461444820929320

---

From: Eliot Lear <[email-masked]>
Date: Fri, 30 Apr 2021 10:59:34 +0200

+1.

Eliot

> On 29 Apr 2021, at 23:25, John Levine <[email-masked]> wrote:
> 
> [email-masked]

---

From: Lloyd W <[email-masked]>
Date: Fri, 30 Apr 2021 19:07:02 +1000

Version control belongs with the RFC Editor function, where the RFC Editor can reference the NIST document and provide a level of indirection and any added guidance.

This makes sense; a small US standards development organisation (SDO) referencing the work of a larger, older, better resourced US government SDO that has thought about this. After all, the IETF is mostly American, and this is quite appropriate for IETF LLC.

The level of indirection through the volunteers on github is not needed.
Establishing TERM WG to control a github resource is not needed.

Lloyd Wood
[email-masked]

> On 30 Apr 2021, at 18:04, Niels ten Oever <[email-masked]> wrote:
> 

I also have a signature.

---

From: Keith Moore <[email-masked]>
Date: Fri, 30 Apr 2021 06:49:53 -0400

> Version control belongs with the RFC Editor function, where the RFC Editor can reference the NIST document and provide a level of indirection and any added guidance.

+1

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 30 Apr 2021 08:54:29 -0400

I can live with pointing to the NIST work.
I hope that we can find ways to address a number of the other issues 
that have been mentioned in this discussion.

Yours,
Joel

---

From: Bob Hinden <[email-masked]>
Date: Fri, 30 Apr 2021 13:57:07 -0700

> On Apr 30, 2021, at 3:49 AM, Keith Moore <[email-masked]> wrote:
> 

I read the NIST document and think it is very good, I agree we should us it.

+1 to the RFC Editor providing a current reference.    Over time, there may be other documents we may want to reference and think the RFC Editor could handle that as well.

Bob

---

From: "John Levine" <[email-masked]>
Date: 30 Apr 2021 20:36:44 -0400

>https://doi.org/10.6028/NIST.IR.8366

I reviewed the report and the section of the Chicago Manual of Style to which it
refers, and also the section of the Chicago Manual of Style that it includes
by reference.

I think this document is better than anything we are likely to come up with on our own,
and it would align our practices with other SDOs, so I encourage us to adopt it and
turn our attention to other issues of IETF culture.

R's,
John

PS: the online Chicago Manual is behind a paywall, but for anyone who wants to look at it,
you can get a 30 day free trial or do what editors have done for the past century and buy
a paper copy.  Paper copies are cheaper than the cheapest subscription so I went the paper route.