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

From: "Salz, Rich" <[email-masked]>
Date: Sat, 1 May 2021 14:30:46 +0000

>   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.

Totally agree.  Glad to see emerging consensus for this.  Lars, how do we make that happen, procedurely?

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Sat, 1 May 2021 09:07:49 -0700 (PDT)

> Totally agree.  Glad to see emerging consensus for this.  Lars, how do we make that happen, procedurely?

I partially agree.  It is good in its content and forum EXCEPT it refers
to what we know to be unpublished drafts of the IETF, the fact that it
appears to have used such input is bothersome to me.  The fact that it
published such references in a standards document is beyond me.

-- 
Rod Grimes                                                 [email-masked]

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 1 May 2021 16:27:17 +0000

Did you read the section?  It says:

Terminology, Power, and Inclusive Language in Internet-Drafts and RFCs is currently an internet draft that does not reflect IETF consensus. This document suggests how editors of Internet-Drafts and RFCs can and should avoid exclusionary language and incorporate alternative, inclusive language in order to improve technical IETF documentation.

"does not reflect IETF consensus"

It covers other "in progress" efforts to, such as GitHub renaming, ISO report that was submitted but not approved, etc.

And the whole thing isn't a standard (like AES, etc).  It's a document to provide guidance.

---

From: [email-masked]
Date: Sat, 01 May 2021 22:24:18 -0400

On 01.05.2021 12:07, Rodney W. Grimes wrote:
>>> 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.
>> 

I pretty much agree with the agreements above, including that I am 
tolerant about NIST's letting users know about some un- or semi-official 
discussions.  But I see a pigeonhole or two not fully swept out.

The NIST expliticly says it is "guidance" for NIST internal staff, not a 
standard.  The TERM WG draft charter says to align efforts with broader 
activities in the industry.  So working within that spirit of friendly 
cooperation it seems fine not to create more words to be read, but 
instead just mention (1)the NIST as a reputable source of specific 
guidance, and (2)the Chicago _Manual of Style_ for general guidance.  
For that, someone--the RFC Editor?--has to aggree this is a good idea, 
if they will be the one(s) to initiate and maintain the slight addition 
to their responsibility.

But I haven't seen any discussion of failure paths.  Being extra 
cautious given the specific issue involved, which has developed over a 
lllooonnnggg period of complaints, it might be worth explicitly 
discussing who would be responsible for handling any complaints.  If 
IETF were to receive any, would they just shuttle them over to NIST?  To 
who at NIST?  By what process of "shuttling"?  And so on.  Would there 
end up being significant delay involved?  So alternatively, maybe a TERM 
WG should exist just to maintain an RFC which would include the two 
references (to NIST and to CMOS), and end with a "<...> is the 
responsible contact for the RFC".  If it turns out there are no 
complaints or questions, then it isn't taking much time from anyone.  If 
however it would take a lot of time, maybe better to have a separate 
TERM RFC and save time for the ITEF RFC Editor.

But either way efficiently covers all the "effective terminology"s in 
the WG draft, and shows how efficiently to provide high quality guidance 
as requested.  RFCs are available to the public, and the public is more 
or less always in IETF's awareness, but the TERM product itself is 
specifically *responsible* only for what IETF needs for internal 
workings, and should not include any of the polemics that have gotten 
the world to this point.

---

From: Lloyd W <[email-masked]>
Date: Sun, 2 May 2021 12:57:06 +1000

Anticipating exactly this is why

https://datatracker.ietf.org/doc/draft-wood-term-modest-proposal/

calls out the TERM WG as a complaints handler - see around the TERM2 mention.

Having TERM effectively as a volunteer HR department accruing power is dystopian. That's not somewhere you would want to go.

The RFC Editor function needs more authority, not less.

Lloyd Wood
[email-masked]

> On 2 May 2021, at 12:24, [email-masked] wrote:
> 
> But I haven't seen any discussion of failure paths.  Being extra cautious given the specific issue involved, which has developed over a lllooonnnggg period of complaints, it might be worth explicitly discussing who would be responsible for handling any complaints.  If IETF were to receive any, would they just shuttle them over to NIST?  To who at NIST?  By what process of "shuttling"?  And so on.  Would there end up being significant delay involved?  So alternatively, maybe a TERM WG should exist just to maintain an RFC which would include the two references (to NIST and to CMOS), and end with a "<...> is the responsible contact for the RFC".  If it turns out there are no complaints or questions, then it isn't taking much time from anyone.  If however it would take a lot of time, maybe better to have a separate TERM RFC and save time for the ITEF RFC Editor

---

From: Eliot Lear <[email-masked]>
Date: Sun, 2 May 2021 11:44:44 +0200

Hi again,

TL&DR;

Have faith: trust people to do the right thing, given the guidance, and they will almost always do so.  Doing otherwise requires burying ourselves in process.

> On 2 May 2021, at 04:24, [email-masked] <mailto:[email-masked]> wrote:
> 
> But I haven't seen any discussion of failure paths.  Being extra cautious given the specific issue involved, which has developed over a lllooonnnggg period of complaints, it might be worth explicitly discussing who would be responsible for handling any complaints.  If IETF were to receive any, would they just shuttle them over to NIST?  To who at NIST?  By what process of "shuttling"?  And so on.  Would there end up being significant delay involved?  So alternatively, maybe a TERM WG should exist just to maintain an RFC which would include the two references (to NIST and to CMOS), and end with a "<...> is the responsible contact for the RFC".  If it turns out there are no complaints or questions, then it isn't taking much time from anyone.  If however it would take a lot of time, maybe better to have a separate TERM RFC and save time for the ITEF RFC Editor.

The TERM working group draft charter had them putting out non-normative advice, so this is really no different.  And non-normative advice should be sufficient.  Consider this: every document that the IETF produces requires rough consensus, and I cannot see how that consensus would be found for a document that is using some of the more egregious terms, never mind the less settled ones (the term “crazy”, for instance,  appears in only 11 of our RFCs and only three in the last fifteen years, one of which is part of an author email address).

So even if the authors miss the term, there are plenty of opportunities to make a correction, or not if the situation warrants some sort of retention, such as a reference to another standard that has old terminology.

By the way, delay accrues to the community’s favor in this context: author motivations are generally to get a document finished, not to argue over terminology.  By way of example, one of my more recent works used the term “MUD controller”, which one person found confusing, and so the term was changed to “MUD manager”.  Looking back, I wish we would have chosen “MUD slinger”, but at the time it was not worth having a debate over what was proposed during review (QED).

Eliot

---

From: Jari Arkko <[email-masked]>
Date: Sun, 2 May 2021 19:35:56 +0300

> turn our attention to other issues of IETF culture.

No document is perfect but this is certainly good enough. My opinion is that the bulk of the work in this particular topic is over time updating our documents and drafts; having a convenient reference for the guidance is of course helpful, but it is particularly helpful if it lets us focus on the bulk of the work. 

Lets reference this document appropriately for the RFC editor and for our work otherwise; and then get to the actual work :-)

Jari