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

Jim Fenton <fenton@bluepopcorn.net> Wed, 04 June 2025 17:18 UTC

Return-Path: <fenton@bluepopcorn.net>
X-Original-To: ietf@mail2.ietf.org
Delivered-To: ietf@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id DDEC630E71B4; Wed, 4 Jun 2025 10:18:53 -0700 (PDT)
X-Quarantine-ID: <fmvkPKD9moSw>
X-Virus-Scanned: amavisd-new at ietf.org
X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...T_ADDRESS@@ for details. Content previ[...]
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=bluepopcorn.net
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmvkPKD9moSw; Wed, 4 Jun 2025 10:18:52 -0700 (PDT)
Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id BF75F30E71AD; Wed, 4 Jun 2025 10:18:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FiREAkM3kPA7FtrAGbyE4lHt/zpoPuEwx1wMF8Z2YLU=; b=TRc2oammZELauat6ns2NZc29Qn JF4RD3UmvdYq7JromRCDZAa+Wn9mehhiGXdsq/tD5tBcynW2v+y0EEzMP5j27bBieKpizCe/sWuO5 J1rbtC2B6HkL8HqCRpbN+/yft/QC0zBaRI6RISUjy+KkBIKu/1SgPSS8UcovSm8Y2Dgw=;
Received: from [2601:647:6883:8360:21be:c130:2080:c87b] (helo=[10.10.20.169]) by v2.bluepopcorn.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <fenton@bluepopcorn.net>) id 1uMrlH-004qXt-2P; Wed, 04 Jun 2025 10:18:48 -0700
From: Jim Fenton <fenton@bluepopcorn.net>
To: "Julien Maisonneuve (Nokia)" <julien.maisonneuve=40nokia.com@dmarc.ietf.org>
Subject: Re: [Terminology] AUTH48 and "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards"
Date: Wed, 04 Jun 2025 10:18:46 -0700
X-Mailer: MailMate (1.14r5852)
Message-ID: <574F2A65-A012-4C54-BD5D-0A6F6D450523@bluepopcorn.net>
In-Reply-To: <PAXPR07MB79996385E8E65A292FD8F754926CA@PAXPR07MB7999.eurprd07.prod.outlook.com>
References: <CAMEWqGtvD8ATWhgYjeVwmBjW7ZUtcVccSKLqdin=7W_UL7Dm7A@mail.gmail.com> <PAXPR07MB79996385E8E65A292FD8F754926CA@PAXPR07MB7999.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_2FF71BF8-35F7-4ED5-8483-AF63B3C62B00_="
Embedded-HTML: [{"plain":[574,3741],"uuid":"B1BD220D-DF96-4F0F-B5BD-F8042A1E8373"}]
Message-ID-Hash: SMONZYTQOAFUFLHLXJM3SCLDNL34QFV6
X-Message-ID-Hash: SMONZYTQOAFUFLHLXJM3SCLDNL34QFV6
X-MailFrom: fenton@bluepopcorn.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ietf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Q Misell <q=40as207960.net@dmarc.ietf.org>, ietf@ietf.org, terminology@ietf.org, The IESG <iesg@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
List-Id: "IETF-Discussion. This is the most general IETF mailing list, intended for discussion of technical, procedural, operational, and other topics for which no dedicated mailing lists exist." <ietf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/FtxjueNCwaydx1uCrwrnH9t7K9E>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Owner: <mailto:ietf-owner@ietf.org>
List-Post: <mailto:ietf@ietf.org>
List-Subscribe: <mailto:ietf-join@ietf.org>
List-Unsubscribe: <mailto:ietf-leave@ietf.org>

IESG decided to reference NIST IR 8366 because it said what they wanted 
to say, not because it had any official status as a NIST Interagency 
Report. That hasn’t changed as a result of the withdrawal of 8366 by 
NIST.

As Jean Mahoney pointed out, the Internet Archive copy of NIST IR 8366 
is stable so there isn’t any reason we can’t continue using it. A 
decision to change to a different document like the ISO/IEC document 
should be based on an improvement in content, not a change in official 
status.

-Jim

On 4 Jun 2025, at 4:01, Julien Maisonneuve (Nokia) wrote:

> 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=40as207960.net@dmarc.ietf.org>
> Sent: Wednesday, June 4, 2025 12:27 PM
> To: ietf@ietf.org; terminology@ietf.org
> Cc: The IESG <iesg@ietf.org>
> 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.

> -- 
> Terminology mailing list -- terminology@ietf.org
> To unsubscribe send an email to terminology-leave@ietf.org