Re: AUTH48 and "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards"
S Moonesamy <sm+ietf@elandsys.com> Thu, 05 June 2025 20:40 UTC
Return-Path: <sm@elandsys.com>
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 094863178F15 for <ietf@mail2.ietf.org>; Thu, 5 Jun 2025 13:40:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com
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 YROAkyobpQZF for <ietf@mail2.ietf.org>; Thu, 5 Jun 2025 13:40:23 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by mail2.ietf.org (Postfix) with ESMTP id 1B2793178F12 for <ietf@ietf.org>; Thu, 5 Jun 2025 13:40:23 -0700 (PDT)
Received: from DESKTOP-K6V9C2L.elandsys.com ([102.117.120.150]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 555Ke9bP009479 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jun 2025 13:40:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=elandsys.com; s=mail; t=1749156020; x=1749242420; i=@elandsys.com; bh=yKmsLIn7NcKke0gvZaMDkt1EdjrtjMdLXgNUIE71NQA=; h=Date:To:From:Subject:In-Reply-To:References; b=RkC7LWSSHMqvwIV8wpJ4/BckyBK2VBbjMYo+l7GujvotufaDiYpJprRz4Dh1TDrz4 2C7ABlBYnVwnqJLNlh6xtbxMxVb0fFxCZQOmpR33FU11wAnci87QvJRYafC7UUsWUA 6d51es0VgCROwy9ezyEElNxcWyCpTaJ4A5eh/waw=
Message-Id: <6.2.5.6.2.20250605123527.0c880180@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 05 Jun 2025 13:39:04 -0700
To: John Scudder <jgs@juniper.net>, ietf@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Subject: Re: AUTH48 and "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards"
In-Reply-To: <CFF09C22-60C7-4932-A987-F2784B56F2F5@juniper.net>
References: <CAMEWqGtvD8ATWhgYjeVwmBjW7ZUtcVccSKLqdin=7W_UL7Dm7A@mail. gmail.com> <6.2.5.6.2.20250604152828.0dd1eec0@elandnews.com> <63700684BE1124344C81DAE2@PSB> <6.2.5.6.2.20250605003009.0e1b0728@elandnews.com> <CFF09C22-60C7-4932-A987-F2784B56F2F5@juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: W2V65XFWW7RCVNVS73Q5HMEFMLGCSW7G
X-Message-ID-Hash: W2V65XFWW7RCVNVS73Q5HMEFMLGCSW7G
X-MailFrom: sm@elandsys.com
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
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/56ElfLPcllPTHJmzImN_s-HRRkk>
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>
Hi John, At 11:38 AM 05-06-2025, John Scudder wrote: >I don't see where Q says that [1]. It's not in >the reply from Jean [2] either, which quotes the >standard question that the RPC asks for all >documents during AUTH48 and therefore is presumably verbatim what Q was asked: There was a question some time back to make the AUTH48 publicly accessible and a decision was taken on that in or around February 2022. The email in which the script was mentioned is archived at https://mailarchive.ietf.org/arch/msg/auth48archive/Yw3JluJcYFE_jc6TDId0fur13JE/ >For that matter, I don't know what "the script" >you refer to might be. (Given the context of our >discussion, the most obvious reading of "the >script" is that you imagine there's some >automation, a la idnits, that's supposed to do this work.) Yes. >Insofar as the question youâve represented >isn't the one Q was asked [3], I don't think >it's possible to come to any conclusion about "efficiency". > >If it would be correct to rewrite your last >sentence as find out whether procedural steps >1-3 might have missed then at least I can >understand what you're saying. I still disagree >with your conclusion that it's "inefficient", though, for two reasons: >: > >First, every one of the parties in your list is >a fallabile human (or group of humans). Things >that can be automated, should be, and then one >might complain about "inefficiency" if the >authors are asked to repeat the work. What we >have left, can't be automated (or hasn't been). >Making judgement calls about terminology is inherently non-automatable [4]. I agree that it is a matter of context (re. judgement calls). >Second, none of the parties in your list has >been tasked with ensuring the stylistic >integrity of the document as a primary >responsibility. Many people make a good-faith >attempt, but in the end, we have a professional >staff for that: the RFC Editor. Indeed, more >than once over the last fiew years, the argument >has been made (on this list, even) that Area >Directors are doing too much editorial review, >and should back off and leave it to the >professionals. In particular, as AD I heard more >than once that it wasn't my job to address >readability and style issues in the documents I >reviewed, other than the most grossly disqualifying ones. > >In summary, I don't think there's something >broken here [5], so let's not fix it. Once in a while, I might notice a nit when I read a draft. I would send an email to the author if we interacted previously. Sometimes, I forget about it as it can be a bit distracting. There can be different opinions on the depth and breath of a review or readability. Regards, S. Moonesamy
- RE: AUTH48 and "Guidance for NIST Staff on Using … Adrian Farrel
- AUTH48 and "Guidance for NIST Staff on Using Incl… Q Misell
- Re: AUTH48 and "Guidance for NIST Staff on Using … Brian Carpenter
- RE: [Terminology] AUTH48 and "Guidance for NIST S… Julien Maisonneuve (Nokia)
- Re: AUTH48 and "Guidance for NIST Staff on Using … Nick Hilliard
- Re: [Terminology] AUTH48 and "Guidance for NIST S… Salz, Rich
- Re: AUTH48 and "Guidance for NIST Staff on Using … Brian E Carpenter
- Re: AUTH48 and "Guidance for NIST Staff on Using … BRUNGARD, DEBORAH A
- Re: [Terminology] AUTH48 and "Guidance for NIST S… Jim Fenton
- Re: AUTH48 and "Guidance for NIST Staff on Using … Bob Hinden
- Re: [Terminology] AUTH48 and "Guidance for NIST S… Jean Mahoney
- Re: AUTH48 and "Guidance for NIST Staff on Using … S Moonesamy
- Re: AUTH48 and "Guidance for NIST Staff on Using … John C Klensin
- Re: AUTH48 and "Guidance for NIST Staff on Using … S Moonesamy
- Re: AUTH48 and "Guidance for NIST Staff on Using … John Scudder
- Re: AUTH48 and "Guidance for NIST Staff on Using … Jay Daley
- Re: AUTH48 and "Guidance for NIST Staff on Using … John Scudder
- Re: AUTH48 and "Guidance for NIST Staff on Using … S Moonesamy
- Re: AUTH48 and "Guidance for NIST Staff on Using … Benson Muite
- Re: AUTH48 and "Guidance for NIST Staff on Using … S Moonesamy
- Re: AUTH48 and "Guidance for NIST Staff on Using … S Moonesamy
- Re: AUTH48 and "Guidance for NIST Staff on Using … Benson Muite
- Re: AUTH48 and "Guidance for NIST Staff on Using … Michael De Roover
- Re: AUTH48 and "Guidance for NIST Staff on Using … Benson Muite
- Re: AUTH48 and "Guidance for NIST Staff on Using … Michael De Roover
- Re: AUTH48 and "Guidance for NIST Staff on Using … S Moonesamy
- Re: AUTH48 and "Guidance for NIST Staff on Using … S Moonesamy