[Terminology] We should avoid childish acronyms as well

Phillip Hallam-Baker <phill@hallambaker.com> Mon, 10 January 2022 01:08 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: terminology@ietfa.amsl.com
Delivered-To: terminology@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015D83A0CD9 for <terminology@ietfa.amsl.com>; Sun, 9 Jan 2022 17:08:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiP8oaF319bS for <terminology@ietfa.amsl.com>; Sun, 9 Jan 2022 17:08:03 -0800 (PST)
Received: from mail-yb1-f171.google.com (mail-yb1-f171.google.com [209.85.219.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CED53A0CDA for <terminology@ietf.org>; Sun, 9 Jan 2022 17:08:03 -0800 (PST)
Received: by mail-yb1-f171.google.com with SMTP id p5so26663515ybd.13 for <terminology@ietf.org>; Sun, 09 Jan 2022 17:08:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=9euAFhVHzBCLDqsz1dNHnDSqAUwejxHO/lAMSlWlv+M=; b=uw1ILD9om6SnN1Y9G9a/mJDVFifytgoPCFfAjAb0hfaxj/XlY8QgJLTYEwXYfnsb7G rTmundfZbOICxDu8GLubzqAnn+b/rF08E+yx37SxG0pYWLC2UApy022Uo5ppLUMiKLfm PCrgxtO3uiTfyeFdKLjKIzqPgD5ubNwwMrSJ82tsMLG+8TDnm61ZLlVXP5+/IZe9ZGKL tJA282mIc4YuO/aTbartROWCoXO5C0Ic1fYYC7iTN7SDkQWP5EGoLrYgr6qdyxmfnsJN O1vN/FdBNyiFfsZyjY+h5P4NPPImUByXs4KLOBzgjT23DxMPlrNJmK4yfh4nq887qeGR J75g==
X-Gm-Message-State: AOAM533xsvbGJGed6EysGExe9jrMY8kSl02JF2SZypizWk0rrL39e5ol tGJbebpCw+rXlZLGglpmwg+zzlcfxXTumR0I8FESFoXJJ/g=
X-Google-Smtp-Source: ABdhPJxMvZTthqZSCFScY9Kl76LkmcyahiW+x/PR5mM0yXHHKF2+QqSL4j46iv1cSkvKzn8v9cKsL2Av3wg5uWIVet0=
X-Received: by 2002:a25:d20a:: with SMTP id j10mr81053383ybg.517.1641776882014; Sun, 09 Jan 2022 17:08:02 -0800 (PST)
MIME-Version: 1.0
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Sun, 09 Jan 2022 20:07:51 -0500
Message-ID: <CAMm+LwgpVzCVkEuv4NMfLJ9KhnAyUoD0sCqKj8WaAfoScuBnMA@mail.gmail.com>
To: terminology@ietf.org
Cc: IAB IAB <iab@iab.org>
Content-Type: multipart/alternative; boundary="000000000000da61ca05d52ff7e4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/terminology/hlnwmDFl8TmFoNXWfCjS9tDCvc8>
Subject: [Terminology] We should avoid childish acronyms as well
X-BeenThere: terminology@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Effective Terminology in IETF Documents <terminology.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/terminology>, <mailto:terminology-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/terminology/>
List-Post: <mailto:terminology@ietf.org>
List-Help: <mailto:terminology-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/terminology>, <mailto:terminology-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Jan 2022 01:08:08 -0000

(cc to IAB because it is their draft)

The message below is from the cryptography list which has public archives.

I read the RFC and found it the bacronym be every bit as childish and
insulting as Peter describes. It is not an argument, it is a bullying,
jeering hit piece. It is completely unprofessional and should never have
been published.

I think it is really important to use the correct language and Master/Slave
etc. come with some serious baggage that we need to leave behind because of
the technical bias they introduce. Giving unintentional offense is also to
be avoided. But coining a trite acronym to insult opposed points of view is
intentional offense.

These issues have since been dealt with by standards track RFCs. I suggest
the best course would be to use that fact as an opportunity to move RFC3424
to HISTORIC.


[Cryptography] Two quick questions about IPsec AH (metzdowd.com)
<https://www.metzdowd.com/pipermail/cryptography/2022-January/037663.html>
Peter Gutmann <pgut001@cs.auckland.ac.nz>

Thu, Jan 6, 11:31 PM (3 days ago)

to *Peter*, Phillip, R, Cryptography
Phillip Hallam-Baker <phill@hallambaker.com> writes:

>I remember sitting in an IPSEC meeting at the Dallas IETF and hearing the
AD
>call this 'a feature'.

Yup, I remember that too (not at the Dallas IETF but elsewhere).  The
thinking
was "IPsec will be bigger than NAT so if we make sure it breaks NAT, NAT
will
go away".

This anti-NAT crusade within the IETF persisted for a long, long time.  Look
at RFC 3424 for example, which invented a childish backronym "UNSAF" to
refer
to NAT-transversal mechanisms so it can talk about UNSAF clients and UNSAF
servers throughout.  Section 4 is particular amusing, describing the various
levels of self-flagellation that any UNSAF mechanism is required by the IAB
to
subject itself to.

Peter.