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

["Julien Maisonneuve (Nokia)" <[e-mail]>]

Administratively the NIST document no longer exists, no amount of copy will change that.
Unless the RFC editor insists on using the document that no longer exists (in which case someone needs to talk to him/her), using the equivalent ISO/IEC document you pointed to appears to be a sound approach to respect inclusivity in an international standards environment.
J.

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


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.


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.