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

[S Moonesamy <[e-mail]>]

Hi John,
At 12:03 AM 05-06-2025, John C Klensin wrote:
>While many exceptions have been made on a case-by-case basis,
>charging for ISO and IEC Standards documents obtained directly from
>the ISO or IEC sites in Geneva is routine, the rule rather than the
>exception.  It is also common for an ISO/IEC standards document,
>especially those from ISO/IEC JTC1, to be available from ISO, from
>IEC, and from one or more national standards bodies, often at
>different prices.  The proprietary of referencing such documents from
>IETF specifications has been debated endlessly; the conclusion has
>been that, like other encumbered technologies, decisions are made on
>a case by case basis.   With the example you site of the basic syntax
>for ASN.1, decisions were made years and years ago that the IETF had
>little choice but to cite it although other sets of syntax rules were
>preferred for most specifications.  While it is not clear to me what
>that ASN.1 spec has to do with the Inclusive Language question, I am,
>more generally, not clear what point you are trying to make and what
>it has to with with the NIST document on inclusive language
>(apparently caught up in the current US Administration's attack on
>anything they consider DEI) and IETF specifications.

I explained how voluntary standards work during a talk which I gave a 
few weeks ago.  I read the recent emails to the last-call mailing 
list and this mailing list.  It prompted me to think about what would 
make a difference to a person in a technology limited economy.  In my 
opinion, the economic option could be more persuasive.

I agree with you that, sometimes, one does not have much of a choice 
when it comes to citing standards which are written by other standards bodies.

The NIST document is more of an "instructions to authors".  It's not 
a "best practice" from a procedural standpoint.  Here's the flow for 
an I-D to get to the RFC Production Center:

   1. The I-D is reviewed by an Area Director.

   2. The community is given some time to review the I-D.

   3. The I-D is reviewed by the Internet Engineering Steering Group (IESG).

Let's assume that an author wrote something which might be against 
some rule.  It would only get through if the Area Director, the 
community and the Internet Engineering Steering Group were not paying 
attention.  Q was asked to go and find out whether the script might 
have missed some words.  I don't find that very efficient.

As for the U.S. National Institute of Standards and Technology 's 
(NIST) retraction of one of its documents, it was politically 
convenient for the 2021-IESG to take the NIST path to avoid 
additional debate.  Based on what I read from Adrian, maybe the 
2025-IESG is unmotivated to write about that topic.

Regards,
S. Moonesamy