RE: AUTH48 and "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards"

[Adrian Farrel <[e-mail]>]

Hey there, Q.

 

I raised this with the IESG “some while ago.”

 

Note that the reference in the IESG statement [2] has been replaced with a link to the NIST document in the Wayback Machine.

 

I offered to the IESG to make our own document essentially capturing the list of terms in an RFC, but omitting the discourse. The IESG did not take me up on this offer, and experience has taught me not to invest work on things that the IESG might easily block through conscious action or neglect.

 

Cheers,

Adrian

 

From: Q Misell <q=[e-mail]> 
Sent: 04 June 2025 11:27
To: [e-mail]; [e-mail]
Cc: The IESG <[e-mail]>
Subject: AUTH48 and "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards"

 

Moin all,

 

I currently have an RFC in the AUTH48 stage, and as part of this the RFC editor asks me to review my text for possible issues around inclusive and respectful language, or rather lack thereof.

Unfortunately, the accepted reference document to check language against, and to provide guidance on the construction of inclusive text is NIST 8366 "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards". There is nothing wrong with the (former) contents of this document, rather that if one tries to access it nowaday they are presented with a 1 page PDF simply stating that "this paper has been withdrawn to comply with executive order (E.O.) 14151" - in essence, President Trump has such a gripe with DEI that we can no longer write inclusive RFCs.

 

I recognise this situation is not anyone with the IETF community's fault - its a ludicrous situation to be placed in by the political whims of a wannabe authoritarian. But the problem exists, and we should probably do something about it. As a starting point, I suggest we adopt the joint inclusive language guidance of the ISO and the IEC [1]; as these are both well respected international standards organisations, this maintains the stated goal of adopting NIST 8366 - in that the language used in the IETF is standardised across industry [2].

 

I am, of course, open to other suggestions about what to do about this situation; and I particularly encourage the IESG to put forward their suggestions to the community.

 

For now, I will continue editing my RFC based on my understanding of inclusive language, and hope that I do not make any mistakes that a solid reference would've prevented.

 

Q

 

[1]: https://iec.ch/system/files/2024-09/iec_doc_topical_inclusive-terminology-guidance_fa_lr.pdf

[2]: https://datatracker.ietf.org/doc/statement-iesg-iesg-statement-on-inclusive-language-20210511/

  _____  

Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574> , LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876> . UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively.