From nobody Sat Jan 8 10:29:19 2022 Return-Path: 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 2B4973A19EF for ; Sat, 8 Jan 2022 10:29:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.27 X-Spam-Level: X-Spam-Status: No, score=0.27 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HDRS_LCASE_IMGONLY=0.099, HTML_IMAGE_ONLY_12=2.059, HTML_IMAGE_RATIO_02=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, 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 WcIzMNkazN3J for ; Sat, 8 Jan 2022 10:29:12 -0800 (PST) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD5073A19F2 for ; Sat, 8 Jan 2022 10:29:09 -0800 (PST) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0R5E0KO0OM0JZ8@wwwlocal.goatley.com> for terminology@ietf.org; Sat, 08 Jan 2022 12:29:07 -0600 (CST) Received: from [10.74.74.210] (69-12-173-8.static.dsltransport.net [69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0R5E005ACM0DX0@trixy.bergandi.net> for terminology@ietf.org; Sat, 08 Jan 2022 10:29:01 -0800 (PST) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO [10.74.74.210]) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Sat, 08 Jan 2022 10:29:01 -0800 Date: Sat, 08 Jan 2022 10:29:06 -0800 From: Dan Harkins To: terminology@ietf.org Message-id: <370703f2-1d55-223d-647e-75c649bb5b3c@lounge.org> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_TUOfqPKailDUxCDmgbPcZQ)" Content-language: en-US User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO [10.74.74.210]) X-PMAS-Software: PreciseMail V3.3 [220107] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: [Terminology] normalizing pronoun sharing X-BeenThere: terminology@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Effective Terminology in IETF Documents List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jan 2022 18:29:17 -0000 This is a multi-part message in MIME format. --Boundary_(ID_TUOfqPKailDUxCDmgbPcZQ) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 8BIT   The prophesy of Les White.... https://blog.apaonline.org/2018/03/20/normalizing-the-use-of-preferred-pronouns-at-philosophy-conferences/ -- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius --Boundary_(ID_TUOfqPKailDUxCDmgbPcZQ) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 8BIT
  The prophesy of Les White....

https://blog.apaonline.org/2018/03/20/normalizing-the-use-of-preferred-pronouns-at-philosophy-conferences/


-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius
--Boundary_(ID_TUOfqPKailDUxCDmgbPcZQ)-- From nobody Sun Jan 9 17:08:09 2022 Return-Path: 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 ; 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 ; 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 ; Sun, 9 Jan 2022 17:08:03 -0800 (PST) Received: by mail-yb1-f171.google.com with SMTP id p5so26663515ybd.13 for ; 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 Date: Sun, 9 Jan 2022 20:07:51 -0500 Message-ID: To: terminology@ietf.org Cc: IAB IAB Content-Type: multipart/alternative; boundary="000000000000da61ca05d52ff7e4" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 01:08:08 -0000 --000000000000da61ca05d52ff7e4 Content-Type: text/plain; charset="UTF-8" (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) Peter Gutmann Thu, Jan 6, 11:31 PM (3 days ago) to *Peter*, Phillip, R, Cryptography Phillip Hallam-Baker 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. --000000000000da61ca05d52ff7e4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(cc to IAB because it is their draft)

The message below is from the crypto= graphy list which has public archives.

I read the RFC and found it the=C2=A0bacronym 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 nev= er 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 i= s intentional offense.

Th= ese issues have since been dealt with by standards track RFCs. I suggest th= e best course would be to use that fact as an opportunity to move RFC3424 t= o HISTORIC.

[Cryptography= ] Two quick questions about IPsec AH (metzdowd.com)

Peter Gutmann= =C2=A0<pgut001@cs.auckland.ac.nz>

<= br>
Thu, Jan 6, 11:31 PM (3 days ago)

3D""
3D""=
to=C2=A0Peter,=C2=A0Phillip,=C2=A0R,= =C2=A0Cryptography
=3D""
Phillip Hallam-Baker <phill@hallambaker.com= > writes:

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

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

This anti-NAT crusade = within the IETF persisted for a long, long time.=C2=A0 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 UN= SAF
servers throughout.=C2=A0 Section 4 is particular amusing, describin= g the various
levels of self-flagellation that any UNSAF mechanism is re= quired by the IAB to
subject itself to.

P= eter.
--000000000000da61ca05d52ff7e4-- From nobody Mon Jan 10 03:28:16 2022 Return-Path: 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 3B9553A139E; Mon, 10 Jan 2022 03:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.679 X-Spam-Level: X-Spam-Status: No, score=-0.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FONT_INVIS_MSGID=1.217, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 2fw7sEVvcHQf; Mon, 10 Jan 2022 03:28:09 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36F663A139C; Mon, 10 Jan 2022 03:28:09 -0800 (PST) Received: from p200300dee733e7009840474daf18e476.dip0.t-ipconnect.de ([2003:de:e733:e700:9840:474d:af18:e476]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1n6sqK-0000tz-IX; Mon, 10 Jan 2022 12:28:04 +0100 From: Mirja Kuehlewind Message-Id: <11986BE7-1C65-49F8-8615-2A622C6B311E@kuehlewind.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_587BCFB6-2866-4182-A84D-DA435EA34B52" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 10 Jan 2022 12:28:02 +0100 In-Reply-To: Cc: terminology@ietf.org, IAB IAB To: Phillip Hallam-Baker References: X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1641814089;26724deb; X-HE-SMSGID: 1n6sqK-0000tz-IX Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 11:28:14 -0000 --Apple-Mail=_587BCFB6-2866-4182-A84D-DA435EA34B52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi PHB, Thanks for flagging the discussion below. I agree that we have to be = careful when selecting acronyms and in the IESG there are often = discussions about picking appropriate acronyms for working group which = are on the one hand meaningful but also don=E2=80=99t suggest a wrong = associations or even harass anybody. This is quite hard and sometimes we = get it wrong. For RFC3424, even if we can argue about the acronym (and please note = that the mechanisms discussed are not NAT itself but mechanisms that = have been developed to circumvent any unintended consequences of NAT), I = don=E2=80=99t follow you argument that this document "is completely = unprofessional and should never have been published=E2=80=9D and as such = also don=E2=80=99t see that making it historic would be adequate. Also note that the status historic is used for specification with have = "been superseded by a more recent specification or is for any other = reason considered to be obsolete=E2=80=9D (RFC2026). Not sure how to = apply this to an IAB document. Also note that IAB documents are not = IETF-consensus documents but merely documents that provide guidance to = the community form the IAB at that time. Mirja > On 10. Jan 2022, at 02:07, Phillip Hallam-Baker = wrote: >=20 > (cc to IAB because it is their draft) >=20 > The message below is from the cryptography list which has public = archives. >=20 > 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. >=20 > 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. >=20 > 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. >=20 >=20 > [Cryptography] Two quick questions about IPsec AH (metzdowd.com) = = > Peter Gutmann > >=20 >=20 > Thu, Jan 6, 11:31 PM (3 days ago) >=20 >=20 >=20 > to Peter, Phillip, R, Cryptography >=20 > Phillip Hallam-Baker > writes: >=20 > >I remember sitting in an IPSEC meeting at the Dallas IETF and hearing = the AD > >call this 'a feature'. >=20 > 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". >=20 > 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. >=20 > Peter. > --=20 > Terminology mailing list > Terminology@ietf.org > https://www.ietf.org/mailman/listinfo/terminology --Apple-Mail=_587BCFB6-2866-4182-A84D-DA435EA34B52 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = PHB,

Thanks for = flagging the discussion below. I agree that we have to be careful when = selecting acronyms and in the IESG there are often discussions about = picking appropriate acronyms for working group which are on the one hand = meaningful but also don=E2=80=99t suggest a wrong associations or even = harass anybody. This is quite hard and sometimes we get it = wrong.

For = RFC3424, even if we can argue about the acronym (and please note that = the mechanisms discussed are not NAT itself but mechanisms that have = been developed to circumvent any unintended consequences of NAT), I = don=E2=80=99t follow you argument that this document "is completely unprofessional and should never have been = published=E2=80=9D and as such also don=E2=80=99t see that making it = historic would be adequate.

Also note that the status historic is used = for specification with have "been superseded by a more = recent specification or is for = any other reason considered to be obsolete=E2=80=9D (RFC2026). Not = sure how to apply this to an IAB document. Also note that IAB = documents are not IETF-consensus documents but merely = documents that provide guidance to the community form the IAB = at that time.

Mirja



On 10. Jan 2022, at 02:07, Phillip = Hallam-Baker <phill@hallambaker.com> wrote:

(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.


Peter Gutmann <pgut001@cs.auckland.ac.nz>


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

3D""
3D""
to PeterPhillipRCryptography
3D""
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.
--
Terminology mailing list
Terminology@ietf.org
https://www.ietf.org/mailman/listinfo/terminology

= --Apple-Mail=_587BCFB6-2866-4182-A84D-DA435EA34B52-- From nobody Mon Jan 10 05:24:00 2022 Return-Path: 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 F40923A081B for ; Mon, 10 Jan 2022 05:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 d0IHsLg0lZGn for ; Mon, 10 Jan 2022 05:23:52 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 B110B3A0819 for ; Mon, 10 Jan 2022 05:23:52 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id e25so14721552qkl.12 for ; Mon, 10 Jan 2022 05:23:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=++71o/XAs29qYVLy2bAcLsm0T6pVmdrUcGu7uBPQKu0=; b=lT/zND4Pu50t0XQmXuZG+2AAsjhSAm1iq7s/VIt7yJ7dcCtZvsporR2yN1eL5mwAd1 kE8HvewFRdGTnN7yDSgx8o7sjX/Dm3GLSu8WxT0Ir9J9PmbYN1wcakH6/3jbnL7duvkD JMRV+VmUupigAhsksMyXciGJtubl1pwSTNJfb1IKX7ffxReMRof9Wzeub/1Xl9+jK3ip kNBbG/tVcBIGN8rhax4GKtdfPPGzcb67pk9mb7elZ89kp0te3lgNAqd8lPWj7heP7wCC zY3kFoCEWwkOhoPG1JOhUsu3XizbyYBogzUj/QmaL/76FSmjkXKcC6cclBe7oZuFtztV Nfwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=++71o/XAs29qYVLy2bAcLsm0T6pVmdrUcGu7uBPQKu0=; b=xOpFdx4J5FCpZ5pUEx8WgwUqC3uOOYwvIvunaelVF1tzPO/cUBLlisshfo1qW4LIYO wzu3usSemhXhJ059t3StFrZNhduvp+WrwcJujBEhCiSPkRJQEftYQoSgiZmuH+8UAfPv t/koaw8rZx15Dl6xEmN3Yhd+eGoCkrBD96R9AB23AaChsdbEDCZTjhvBAYzcvAALr+Ls 9XMTojhI2LDy3sDkXSyXOJ3bFrmVDqUWJlqiWpTZotQzfnnP5HolFG4qvEvjFVEutxtD 5tX4t8l8hLLgdeehtKnkin+H5pdef23Q0pEyYGAK4sVW//6tT8EP6EUa+OXpVss+uzp3 CeQQ== X-Gm-Message-State: AOAM5329JCxvrASC2gQPs0Ezg8Y3H0E3mYU4qCRUk4oI9iV57k4qAqvg k/egNoR8EYFMBLZGA1I51wM= X-Google-Smtp-Source: ABdhPJw7NcXJR6NxeGydE+J3XgErx4W+XL3VZYhd6mMDAdTHdLz8quM/4W/YwotG4AWoTL9hQvPJqQ== X-Received: by 2002:a37:b586:: with SMTP id e128mr52025278qkf.268.1641821030354; Mon, 10 Jan 2022 05:23:50 -0800 (PST) Received: from MN2PR06MB6559.namprd06.prod.outlook.com ([2603:1036:302:4123::5]) by smtp.gmail.com with ESMTPSA id v7sm4489641qkp.30.2022.01.10.05.23.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Jan 2022 05:23:49 -0800 (PST) From: Phillip Hallam-Baker To: Mirja Kuehlewind , Phillip Hallam-Baker CC: "terminology@ietf.org" , IAB IAB Thread-Topic: [Terminology] We should avoid childish acronyms as well Thread-Index: AUFhb2Z6F9JkE+X+f6vrnU5WtfjpPEUyMTQ3qx/UqD8= X-MS-Exchange-MessageSentRepresentingType: 1 Date: Mon, 10 Jan 2022 13:23:48 +0000 Message-ID: References: <11986BE7-1C65-49F8-8615-2A622C6B311E@kuehlewind.net> In-Reply-To: <11986BE7-1C65-49F8-8615-2A622C6B311E@kuehlewind.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_MN2PR06MB6559A862E85C2910969F7646F8509MN2PR06MB6559namp_" MIME-Version: 1.0 Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 13:23:58 -0000 --_000_MN2PR06MB6559A862E85C2910969F7646F8509MN2PR06MB6559namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The acronym plays absolutely no role in the document other than repeatedly = referring to a set of technologies they dislike as UNSAFE. Let=92s call that a CHLDSH acronym. The problem with reading a paper with a= CHLDSH acronym document is that all the time you are reading the arguments= you are thinking about the tactic of being CHLDSH instead of what the docu= ment is supposedly about. I find the document next to impossible to follow because the term really is= n=92t well defined except as =91mechanisms trying to do something we oppose= on principle=92. It=92s like reading a paper that keeps shouting UNCLEAN! UNCLEAN! Looking at the paper, it is making me think that a lot of IETF argument con= sists of picking a random position and insisting it is the right one becaus= e it is the position that all right thinking people believe. Then suggestin= g anyone who is challenging this random position is the person =91being dif= ficult=92. The point is that the paper is 1) showing disrespect to people holding an o= pposed technical position and 2) repeatedly saying, =91hey look at us, we a= re the IAB, we can show disrespect and you have to like it=92. Yuk Get Outlook for iOS ________________________________ From: Mirja Kuehlewind Sent: Monday, January 10, 2022 6:28:02 AM To: Phillip Hallam-Baker Cc: terminology@ietf.org ; IAB IAB Subject: Re: [Terminology] We should avoid childish acronyms as well Hi PHB, Thanks for flagging the discussion below. I agree that we have to be carefu= l when selecting acronyms and in the IESG there are often discussions about= picking appropriate acronyms for working group which are on the one hand m= eaningful but also don=92t suggest a wrong associations or even harass anyb= ody. This is quite hard and sometimes we get it wrong. For RFC3424, even if we can argue about the acronym (and please note that t= he mechanisms discussed are not NAT itself but mechanisms that have been de= veloped to circumvent any unintended consequences of NAT), I don=92t follow= you argument that this document "is completely unprofessional and should n= ever have been published=94 and as such also don=92t see that making it his= toric would be adequate. Also note that the status historic is used for specification with have "bee= n superseded by a more recent specification or is for any other reason cons= idered to be obsolete=94 (RFC2026). Not sure how to apply this to an IAB do= cument. Also note that IAB documents are not IETF-consensus documents but m= erely documents that provide guidance to the community form the IAB at that= time. Mirja On 10. Jan 2022, at 02:07, Phillip Hallam-Baker > wrote: (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 insul= ting as Peter describes. It is not an argument, it is a bullying, jeering h= it piece. It is completely unprofessional and should never have been publis= hed. 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 o= f the technical bias they introduce. Giving unintentional offense is also t= o 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) Peter Gutmann > Thu, Jan 6, 11:31 PM (3 days ago) [https://mail.google.com/mail/u/0/images/cleardot.gif] [https://mail.google.com/mail/u/0/images/cleardot.gif] to Peter, Phillip, R, Cryptography [https://mail.google.com/mail/u/0/images/cleardot.gif] Phillip Hallam-Baker > = 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 think= ing was "IPsec will be bigger than NAT so if we make sure it breaks NAT, NAT wi= ll go away". This anti-NAT crusade within the IETF persisted for a long, long time. Loo= k at RFC 3424 for example, which invented a childish backronym "UNSAF" to ref= er to NAT-transversal mechanisms so it can talk about UNSAF clients and UNSAF servers throughout. Section 4 is particular amusing, describing the variou= s levels of self-flagellation that any UNSAF mechanism is required by the IAB= to subject itself to. Peter. -- Terminology mailing list Terminology@ietf.org https://www.ietf.org/mailman/listinfo/terminology --_000_MN2PR06MB6559A862E85C2910969F7646F8509MN2PR06MB6559namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The acronym plays absolutely no role in the document other than repeatedly = referring to a set of technologies they dislike as UNSAFE.

Let=92s call that a CHLDSH acronym. The problem with reading a paper with a=  CHLDSH acronym document is tha= t all the time you are reading the arguments you are thinking about the tactic of being CH= LDSH instead of what the document is supposedly about.

I find = the document next to impossible to follow because the term really isn=92t well defined except as =91mechanisms tryin= g to do something we oppose on principle=92.

It=92s = like reading a paper that keeps shouting UNCLEAN! UNCLEAN!

Looking at the paper, it is making me think that a lot of IETF argument con= sists of picking a random position and insisting it is the right one becaus= e it is the position that all right thinking people believe. Then suggestin= g anyone who is challenging this random position is the person =91being difficult=92.

The point is that the paper is 1) showing disrespect to people holding an o= pposed technical position and 2) repeatedly saying, =91hey look at us, we a= re the IAB, we can show disrespect and you have to like it=92.

Yuk


From: Mirja Kuehlewind <= ietf@kuehlewind.net>
Sent: Monday, January 10, 2022 6:28:02 AM
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: terminology@ietf.org <terminology@ietf.org>; IAB IAB <i= ab@iab.org>
Subject: Re: [Terminology] We should avoid childish acronyms as well=
 

Thanks for flagging the discussion below. I agree that we h= ave to be careful when selecting acronyms and in the IESG there are often d= iscussions about picking appropriate acronyms for working group which are o= n the one hand meaningful but also don=92t suggest a wrong associations or even harass anybody. This is quite= hard and sometimes we get it wrong.

For RFC3424, even if we can argue about the acronym (and pl= ease note that the mechanisms discussed are not NAT itself but mechanisms t= hat have been developed to circumvent any unintended consequences of NAT), = I don=92t follow you argument that this document "is completely unprofessional an= d should never have been published=94 and as such also don=92t see that mak= ing it historic would be adequate.

Also note that the status histo= ric is used for specification with have "been superseded by a more re= cent specification or is for any other reason considered to be obsolete=94 (RFC2026). Not sure how= to apply this to an IAB document. Also note that IAB documents are no= t IETF-consensus documents but merely documents that provide = ;guidance to the community form the IAB at that time.

Mirja



On 10. Jan 2022, at 02:07, Phillip Hallam-Baker <phill@hallambaker.com> = wrote:

(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 real= ly important to use the correct language and Master/Slave etc. come with so= me serious baggage that we need to leave behind because of the technical bi= as they introduce. Giving unintentional offense is also to be avoided. But coining a trite acronym to insult oppos= ed points of view is intentional offense.

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


[Cryptography] Two quick questions about IPsec AH (metzdowd.com)

Peter= Gutmann <pgut001@cs.auckland.ac.nz><= /span>

<= br class=3D"">
Thu, Jan 6, 11:31 PM (3 days ago)
<= br class=3D"">
3D""
3D""
to PeterPhillipR,&nb= sp;Cryptography
3D""
Phillip Hallam-Baker <phill@hallambaker.com> writes:

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

Yup, I remember that too (not at the Dallas IETF but elsewhere).&nbs= p; The thinking
was "IPsec will be bigger than NAT so if we make sure it breaks NAT, N= AT 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&qu= ot; to refer
to NAT-transversal mechanisms so it can talk about UNSAF clients and UNSAF<= br class=3D""> servers throughout.  Section 4 is particular amusing, describing the v= arious
levels of self-flagellation that any UNSAF mechanism is required by the IAB= to
subject itself to.

Peter.
--
Terminology mailing list
Terminology@ietf.org=
https://www.ietf.org/mailman/listinfo/terminology

--_000_MN2PR06MB6559A862E85C2910969F7646F8509MN2PR06MB6559namp_-- From nobody Mon Jan 10 11:46:41 2022 Return-Path: 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 8DD633A0FBF for ; Mon, 10 Jan 2022 11:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.613 X-Spam-Level: X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 6y1dgbnQ10vj for ; Mon, 10 Jan 2022 11:46:34 -0800 (PST) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB0603A0FB8 for ; Mon, 10 Jan 2022 11:46:34 -0800 (PST) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0R5I0RCF4EXMPV@wwwlocal.goatley.com> for terminology@ietf.org; Mon, 10 Jan 2022 13:46:34 -0600 (CST) Received: from [10.74.74.210] (69-12-173-8.static.dsltransport.net [69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0R5I00E9GEX5DT@trixy.bergandi.net> for terminology@ietf.org; Mon, 10 Jan 2022 11:46:18 -0800 (PST) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO [10.74.74.210]) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Mon, 10 Jan 2022 11:46:18 -0800 Date: Mon, 10 Jan 2022 11:46:32 -0800 From: Dan Harkins In-reply-to: To: terminology@ietf.org Message-id: <389f5791-14b8-1a91-77fc-1a86048ab5cf@lounge.org> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_oVXTDE/0tKF85z7z7z9Bog)" Content-language: en-US User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO [10.74.74.210]) References: <11986BE7-1C65-49F8-8615-2A622C6B311E@kuehlewind.net> X-PMAS-Software: PreciseMail V3.3 [220110] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 19:46:40 -0000 This is a multi-part message in MIME format. --Boundary_(ID_oVXTDE/0tKF85z7z7z9Bog) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 8BIT   I'm really sorry this is happening to you PHB.   The thing is, I remember back in the late 90s and early aughts when the attitude on NAT was, roughly, "if you NAT the 'net you're not on the 'net", or something like that. There was lots of pushback to discount any security that people pushing NATs claimed. It was the popular sentiment at the time, NATs do not provide security.   So they chose a cutesy acronym. You're right that it's childish but you're wrong that it's bullying. Lots of IETF acronyms are childish. Look at kitten. Even now we have a sedate WG. There's a long history of these sorts of acronyms in the IETF.   If you want to start a campaign to eliminate cutesy and childish acronyms in the IETF then I wish you luck. But leave RFC 3424 alone. This is why I was so against the whole terminology push to begin with. It would never stop with just "blacklist" or "master/slave", there would have to be a continual stream of documents/terms that would need to be addressed to justify the effort. The inquisition will have to close if its scope isn't continually expanded. Better to not start it in the first place.   Dan. On 1/10/22 5:23 AM, Phillip Hallam-Baker wrote: > The acronym plays absolutely no role in the document other than > repeatedly referring to a set of technologies they dislike as UNSAFE. > > Let’s call that a CHLDSH acronym. The problem with reading a paper > with a CHLDSH acronym document is that all the time you are reading > the arguments you are thinking about the tactic of being > CHLDSH instead of what the document is supposedly about. > > I find the document next to impossible to follow because the term > really isn’t well defined except as ‘mechanisms trying to do something > we oppose on principle’. > > It’s like reading a paper that keeps shouting UNCLEAN! UNCLEAN! > > Looking at the paper, it is making me think that a lot of IETF > argument consists of picking a random position and insisting it is the > right one because it is the position that all right thinking people > believe. Then suggesting anyone who is challenging this random > position is the person ‘being difficult’. > > The point is that the paper is 1) showing disrespect to people holding > an opposed technical position and 2) repeatedly saying, ‘hey look at > us, we are the IAB, we can show disrespect and you have to like it’. > > Yuk > > > Get Outlook for iOS > ------------------------------------------------------------------------ > *From:* Mirja Kuehlewind > *Sent:* Monday, January 10, 2022 6:28:02 AM > *To:* Phillip Hallam-Baker > *Cc:* terminology@ietf.org ; IAB IAB > *Subject:* Re: [Terminology] We should avoid childish acronyms as well > Hi PHB, > > Thanks for flagging the discussion below. I agree that we have to be > careful when selecting acronyms and in the IESG there are often > discussions about picking appropriate acronyms for working group which > are on the one hand meaningful but also don’t suggest a wrong > associations or even harass anybody. This is quite hard and sometimes > we get it wrong. > > For RFC3424, even if we can argue about the acronym (and please note > that the mechanisms discussed are not NAT itself but mechanisms that > have been developed to circumvent any unintended consequences of NAT), > I don’t follow you argument that this document "is completely > unprofessional and should never have been published” and as such also > don’t see that making it historic would be adequate. > > Also note that the status historic is used for specification with have > "been superseded by a more recent specification or is for any other > reason considered to be obsolete” (RFC2026). Not sure how to apply > this to an IAB document. Also note that IAB documents are not > IETF-consensus documents but merely documents that provide guidance to > the community form the IAB at that time. > > Mirja > > > >> On 10. Jan 2022, at 02:07, Phillip Hallam-Baker >> wrote: >> >> (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) >> >> >> >> Peter Gutmann >> >> >> >> Thu, Jan 6, 11:31 PM (3 days ago) >> >> >> >> to *Peter*, Phillip, R, Cryptography >> >> Phillip Hallam-Baker 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. >> -- >> Terminology mailing list >> Terminology@ietf.org >> https://www.ietf.org/mailman/listinfo/terminology > > -- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius --Boundary_(ID_oVXTDE/0tKF85z7z7z9Bog) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 8BIT
  I'm really sorry this is happening to you PHB.

  The thing is, I remember back in the late 90s and early aughts when the
attitude on NAT was, roughly, "if you NAT the 'net you're not on the 'net",
or something like that. There was lots of pushback to discount any security
that people pushing NATs claimed.
It was the popular sentiment at the time,
NATs do not provide security.

  So they chose a cutesy acronym. You're right that it's childish but you're
wrong that it's bullying. Lots of IETF acronyms are childish. Look at kitten.
Even now we have a sedate WG. There's a long history of these sorts of acronyms
in the IETF.

  If you want to start a campaign to eliminate cutesy and childish acronyms
in the IETF then I wish you luck. But leave RFC 3424 alone. This is why I was
so against the whole terminology push to begin with. It would never stop with
just "blacklist" or "master/slave", there would have to be a continual stream
of documents/terms that would need to be addressed to justify the effort.
The inquisition will have to close if its scope isn't continually expanded.
Better to not start it in the first place.

  Dan.

On 1/10/22 5:23 AM, Phillip Hallam-Baker wrote:
The acronym plays absolutely no role in the document other than repeatedly referring to a set of technologies they dislike as UNSAFE.

Let’s call that a CHLDSH acronym. The problem with reading a paper with a CHLDSH acronym document is that all the time you are reading the arguments you are thinking about the tactic of being CHLDSH instead of what the document is supposedly about.

I find the document next to impossible to follow because the term really isn’t well defined except as ‘mechanisms trying to do something we oppose on principle’.

It’s like reading a paper that keeps shouting UNCLEAN! UNCLEAN!

Looking at the paper, it is making me think that a lot of IETF argument consists of picking a random position and insisting it is the right one because it is the position that all right thinking people believe. Then suggesting anyone who is challenging this random position is the person ‘being difficult’.

The point is that the paper is 1) showing disrespect to people holding an opposed technical position and 2) repeatedly saying, ‘hey look at us, we are the IAB, we can show disrespect and you have to like it’.

Yuk


From: Mirja Kuehlewind <ietf@kuehlewind.net>
Sent: Monday, January 10, 2022 6:28:02 AM
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: terminology@ietf.org <terminology@ietf.org>; IAB IAB <iab@iab.org>
Subject: Re: [Terminology] We should avoid childish acronyms as well
 
Hi PHB,

Thanks for flagging the discussion below. I agree that we have to be careful when selecting acronyms and in the IESG there are often discussions about picking appropriate acronyms for working group which are on the one hand meaningful but also don’t suggest a wrong associations or even harass anybody. This is quite hard and sometimes we get it wrong.

For RFC3424, even if we can argue about the acronym (and please note that the mechanisms discussed are not NAT itself but mechanisms that have been developed to circumvent any unintended consequences of NAT), I don’t follow you argument that this document "is completely unprofessional and should never have been published” and as such also don’t see that making it historic would be adequate.

Also note that the status historic is used for specification with have "been superseded by a more recent specification or is for any other reason considered to be obsolete” (RFC2026). Not sure how to apply this to an IAB document. Also note that IAB documents are not IETF-consensus documents but merely documents that provide guidance to the community form the IAB at that time.

Mirja



On 10. Jan 2022, at 02:07, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

(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.


Peter Gutmann pgut001@cs.auckland.ac.nz


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


to PeterPhillipRCryptography
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.
--
Terminology mailing list
Terminology@ietf.org
https://www.ietf.org/mailman/listinfo/terminology



-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius
--Boundary_(ID_oVXTDE/0tKF85z7z7z9Bog)-- From nobody Mon Jan 10 13:42:00 2022 Return-Path: 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 156DF3A0ECD for ; Mon, 10 Jan 2022 13:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 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_DNSWL_BLOCKED=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 cdVuaI5Y26-a for ; Mon, 10 Jan 2022 13:41:54 -0800 (PST) Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) (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 0A2CC3A0ECB for ; Mon, 10 Jan 2022 13:41:54 -0800 (PST) Received: by mail-yb1-f181.google.com with SMTP id c6so39801642ybk.3 for ; Mon, 10 Jan 2022 13:41:53 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wQ2fSr1wrrZSuYZ2Op+gGTqm2xSGSqimTMPZi74nJ3I=; b=vgaM9bDFaLUWbXGMOmrWbuZA2HUJWZfi0zbPaPVRJtawSq6+G8O3IRFmMf2pEaOQuD xtK7oQJzTO619S7B23/PDrBcWwRWPoCtRHEfXW1WqK2h7QAlYrzgEKOl5D6WK26s2xnb dGyebitecqcAL86Bz4SX74M14GXVln/1PY8EGKECv11+mvZcZMgwx3S5BtPlbBGWephH 4nENdhgTS3ph/+g5xHObDtgJdeJPelXwWa2q+f0s16aLbd19ElWTotyqh31YwM65LZ3L VgIpciFXtz9JL+UyRGiujszUEvgbvl0LGoZcpykwZob+XjEglNyKyUE3S6Xu4JZxz0S1 fAcg== X-Gm-Message-State: AOAM530kU6bEmVT6l+QRY7K6yI/MxdX9jgZ4gFE7PYXUwJIzmiHMxFup yydzzTWKYrOUc0h3+cc5fDeTCmaxfCOISQhE0+s= X-Google-Smtp-Source: ABdhPJw3oUlPPcHYK3fwDZ/rWZC8d5jJbdNnw7aQbPf8/nuYctpsGz7Wz46km5Mf8g13LyQ6EtCIWufL+WR36QIF25w= X-Received: by 2002:a5b:945:: with SMTP id x5mr312558ybq.532.1641850913054; Mon, 10 Jan 2022 13:41:53 -0800 (PST) MIME-Version: 1.0 References: <11986BE7-1C65-49F8-8615-2A622C6B311E@kuehlewind.net> <389f5791-14b8-1a91-77fc-1a86048ab5cf@lounge.org> In-Reply-To: <389f5791-14b8-1a91-77fc-1a86048ab5cf@lounge.org> From: Phillip Hallam-Baker Date: Mon, 10 Jan 2022 16:41:42 -0500 Message-ID: To: Dan Harkins Cc: terminology@ietf.org Content-Type: multipart/alternative; boundary="00000000000072629205d54134f0" Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 21:41:59 -0000 --00000000000072629205d54134f0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Choosing to apply a silly name to yourself is not the same as choosing an insulting name and applying it to other people. I object to the use of the terms 'SJW' and 'NeoCon' to refer to people who have never referred to themselves as such precisely because the intention is to insult and demean. It is argument by name calling. As it happens, I was not the target of RFC 3424 and it would have been pretty brave of the editor to have put her name to it if I had been the target since we both worked for the same company at the time. The reason I am raising it is that the conversations I am seeing in another place and the off-list follow-ups make it very clear that a lot of people were offended and it is very clearly damaging to the reputation of the IETF. On Mon, Jan 10, 2022 at 2:46 PM Dan Harkins wrote: > > I'm really sorry this is happening to you PHB. > > The thing is, I remember back in the late 90s and early aughts when the > attitude on NAT was, roughly, "if you NAT the 'net you're not on the 'net= ", > or something like that. There was lots of pushback to discount any securi= ty > that people pushing NATs claimed. It was the popular sentiment at the > time, > NATs do not provide security. > > So they chose a cutesy acronym. You're right that it's childish but > you're > wrong that it's bullying. Lots of IETF acronyms are childish. Look at > kitten. > Even now we have a sedate WG. There's a long history of these sorts of > acronyms > in the IETF. > > If you want to start a campaign to eliminate cutesy and childish acrony= ms > in the IETF then I wish you luck. But leave RFC 3424 alone. This is why I > was > so against the whole terminology push to begin with. It would never stop > with > just "blacklist" or "master/slave", there would have to be a continual > stream > of documents/terms that would need to be addressed to justify the effort. > The inquisition will have to close if its scope isn't continually expande= d. > Better to not start it in the first place. > > Dan. > > On 1/10/22 5:23 AM, Phillip Hallam-Baker wrote: > > The acronym plays absolutely no role in the document other than repeatedl= y > referring to a set of technologies they dislike as UNSAFE. > > Let=E2=80=99s call that a CHLDSH acronym. The problem with reading a pape= r with a > CHLDSH acronym document is that all the time you are reading the > arguments you are thinking about the tactic of being CHLDSH instead of > what the document is supposedly about. > > I find the document next to impossible to follow because the term really > isn=E2=80=99t well defined except as =E2=80=98mechanisms trying to do som= ething we oppose > on principle=E2=80=99. > > It=E2=80=99s like reading a paper that keeps shouting UNCLEAN! UNCLEAN! > > Looking at the paper, it is making me think that a lot of IETF argument > consists of picking a random position and insisting it is the right one > because it is the position that all right thinking people believe. Then > suggesting anyone who is challenging this random position is the person > =E2=80=98being difficult=E2=80=99. > > The point is that the paper is 1) showing disrespect to people holding an > opposed technical position and 2) repeatedly saying, =E2=80=98hey look at= us, we > are the IAB, we can show disrespect and you have to like it=E2=80=99. > > Yuk > > > Get Outlook for iOS > ------------------------------ > *From:* Mirja Kuehlewind > *Sent:* Monday, January 10, 2022 6:28:02 AM > *To:* Phillip Hallam-Baker > *Cc:* terminology@ietf.org ; > IAB IAB > *Subject:* Re: [Terminology] We should avoid childish acronyms as well > > Hi PHB, > > Thanks for flagging the discussion below. I agree that we have to be > careful when selecting acronyms and in the IESG there are often discussio= ns > about picking appropriate acronyms for working group which are on the one > hand meaningful but also don=E2=80=99t suggest a wrong associations or ev= en harass > anybody. This is quite hard and sometimes we get it wrong. > > For RFC3424, even if we can argue about the acronym (and please note that > the mechanisms discussed are not NAT itself but mechanisms that have been > developed to circumvent any unintended consequences of NAT), I don=E2=80= =99t follow > you argument that this document "is completely unprofessional and should > never have been published=E2=80=9D and as such also don=E2=80=99t see tha= t making it > historic would be adequate. > > Also note that the status historic is used for specification with have "b= een > superseded by a more recent specification or is for any other reason > considered to be obsolete=E2=80=9D (RFC2026). Not sure how to apply this = to an IAB > document. Also note that IAB documents are not IETF-consensus documents b= ut > merely documents that provide guidance to the community form the IAB at > that time. > > Mirja > > > > On 10. Jan 2022, at 02:07, Phillip Hallam-Baker > wrote: > > (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 sugges= t > the best course would be to use that fact as an opportunity to move RFC34= 24 > to HISTORIC. > > > [Cryptography] Two quick questions about IPsec AH (metzdowd.com) > > Peter Gutmann > > Thu, Jan 6, 11:31 PM (3 days ago) > > > to *Peter*, Phillip, R, Cryptography > Phillip Hallam-Baker writes: > > >I remember sitting in an IPSEC meeting at the Dallas IETF and hearing th= e > 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 UNSA= F > 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. > -- > Terminology mailing list > Terminology@ietf.org > https://www.ietf.org/mailman/listinfo/terminology > > > > > -- > "The object of life is not to be on the side of the majority, but to > escape finding oneself in the ranks of the insane." -- Marcus Aurelius > > -- > Terminology mailing list > Terminology@ietf.org > https://www.ietf.org/mailman/listinfo/terminology > --00000000000072629205d54134f0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Cho= osing to apply a silly name to yourself is not the same as choosing an insu= lting name and applying it to other people.

I object to the use of the terms 'SJW' and = 9;NeoCon' to refer to people who have never referred=C2=A0to themselves= as such precisely because the intention is to insult=C2=A0and demean. It i= s argument by name calling.

As it happens, I was not the target of RFC 3424 and it would have been p= retty brave of the editor to have put her name to it if I had been the targ= et since we both worked for the same company at the time. The reason I am r= aising it is that the conversations I am seeing in another place and the of= f-list follow-ups make it very clear that a lot of people were offended and= it is very clearly damaging to the reputation of the IETF.




On Mon, Jan 10, 2022 at 2:46 PM Dan Hark= ins <dharkins@lounge.org> = wrote:
=20 =20 =20

=C2=A0 I'm really sorry this is happening = to you PHB.

=C2=A0 The thing is, I remember back in the late 90s and early aughts when the
attitude on NAT was, roughly, "if you NAT the 'net you'r= e not on the 'net",
or something like that. There was lots of pushback to discount any security
that people pushing NATs claimed.
It was the popular sentiment at the time,
NATs do not provide security.

=C2=A0 So they chose a cutesy acronym. You're right that i= t's childish but you're
wrong that it's bullying. Lots of IETF acronyms are childish. Loo= k at kitten.
Even now we have a sedate WG. There's a long history of these sorts of acronyms
in the IETF.

=C2=A0 If you want to start a campaign to eliminate cutesy and childi= sh acronyms
in the IETF then I wish you luck. But leave RFC 3424 alone. This is why I was
so against the whole terminology push to begin with. It would never stop with
just "blacklist" or "master/slave", there would h= ave to be a continual stream
of documents/terms that would need to be addressed to justify the effort.
The inquisition will have to close if its scope isn't continually expanded.
Better to not start it in the first place.

=C2=A0 Dan.

On 1/10/22 5:23 AM, Phillip Hallam-Baker wrote:
=20
The acronym plays absolutely no role in the document other than repeatedly referring to a set of technologies they dislike as UNSAFE.

Let=E2=80=99s call that a CHLDSH acronym. The problem with read= ing a paper with a=C2=A0CHLDSH=C2=A0acronym document is that all the time you are reading the arguments you are thinking about the tactic of being=C2=A0CHLDSH=C2=A0instead of what the = document is supposedly about.

I find the document next to impossible to follow because the term really isn=E2=80= =99t well defined except as =E2=80=98mechanisms trying to do something we oppose on principle=E2=80=99.

It=E2=80=99s like reading a paper that keeps shouting UNCLEAN! UNCLEAN!<= /div>

Looking at the paper, it is making me think that a lot of IETF argument consists of picking a random position and insisting it is the right one because it is the position that all right thinking people believe. Then suggesting anyone who is challenging this random position is the person =E2=80=98being difficult=E2=80=99.

The point is that the paper is 1) showing disrespect to people holding an opposed technical position and 2) repeatedly saying, =E2=80=98hey look at us, we are the IAB, we = can show disrespect and you have to like it=E2=80=99.

Yuk


= From: Mirja Kuehlewind <ietf@kuehlewind.net>
Sent: Monday, January 10, 2022 6:28:02 AM
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: terminology@ietf.org <terminology@ietf.org>; IAB IAB <iab@= iab.org>
Subject: Re: [Terminology] We should avoid childish acronyms as well
=C2=A0
Hi PHB,

Thanks for flagging the discussion below. I agree that we have to be careful when selecting acronyms and in the IESG there are often discussions about picking appropriate acronyms for working group which are on the one hand meaningful but also don=E2=80=99t suggest a wrong associations or= even harass anybody. This is quite hard and sometimes we get it wrong.

For RFC3424, even if we can argue about the acronym (and please note that the mechanisms discussed are not NAT itself but mechanisms that have been developed to circumvent any unintended consequences of NAT), I don=E2=80=99t f= ollow you argument that this document "is completely unprofessional and should never have been published=E2=80=9D and as such also don=E2=80=99t see that maki= ng it historic=C2=A0would be=C2=A0adequate.

Also note that the status historic is=C2=A0used for specification with=C2=A0have "been superseded by a more recent=C2=A0specif= ication or is for any other reason considered to be obsolete=E2=80=9D (RFC2026).=C2=A0Not sure how to apply this to an IAB document.=C2=A0Also note that IAB documents are not IETF-consensus=C2=A0documents but merely documents=C2=A0that provide=C2=A0guidance to the community form the IAB at that tim= e.

Mirja



On 10. Jan 2022, at 02:07, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

(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=C2=A0bacronym be every bit as childi= sh 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.


Peter Gutmann=C2=A0<pgut001@cs.auckland.ac.nz>

<= br>
T= hu, Jan 6, 11:31 PM (3 days ago)
<= br>

3D""
3D""
to=C2=A0= Peter,=C2=A0P= hillip,=C2=A0R,=C2=A0Cryptography
3D""
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).=C2=A0 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.=C2=A0 Look=
at RFC 3424 for example, which invented a childish backronym "UNSAF" to r= efer
to NAT-transversal mechanisms so it can talk about UNSAF clients and UNSAF
servers throughout.=C2=A0 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.<= br>
Peter.
--
Terminology mailing list
T= erminology@ietf.org
https://www.ietf.org/mailman/listinfo/terminology<= br>



--=20
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius=
--
Terminology mailing list
Terminology@ietf.= org
https://www.ietf.org/mailman/listinfo/terminology
--00000000000072629205d54134f0-- From nobody Mon Jan 10 14:20:24 2022 Return-Path: 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 19E2B3A12DA for ; Mon, 10 Jan 2022 14:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.395 X-Spam-Level: X-Spam-Status: No, score=-1.395 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FONT_INVIS_MSGID=1.217, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, RCVD_IN_DNSWL_BLOCKED=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 Kp9RPhmQQD-F for ; Mon, 10 Jan 2022 14:20:17 -0800 (PST) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AEAD3A12D8 for ; Mon, 10 Jan 2022 14:20:17 -0800 (PST) Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0R5I0VL4MM1SP9@wwwlocal.goatley.com> for terminology@ietf.org; Mon, 10 Jan 2022 16:20:16 -0600 (CST) Received: from [10.74.74.210] (69-12-173-8.static.dsltransport.net [69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0R5I00HCNM19TW@trixy.bergandi.net> for terminology@ietf.org; Mon, 10 Jan 2022 14:20:00 -0800 (PST) Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO [10.74.74.210]) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Mon, 10 Jan 2022 14:19:58 -0800 Date: Mon, 10 Jan 2022 14:20:12 -0800 From: Dan Harkins In-reply-to: To: terminology@ietf.org Message-id: <538e446e-1624-f517-fba0-c8ca4674d522@lounge.org> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_TtNmBq8oWER+YptliaSLaA)" Content-language: en-US User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8) X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO [10.74.74.210]) References: <11986BE7-1C65-49F8-8615-2A622C6B311E@kuehlewind.net> <389f5791-14b8-1a91-77fc-1a86048ab5cf@lounge.org> X-PMAS-Software: PreciseMail V3.3 [220110a] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 22:20:22 -0000 This is a multi-part message in MIME format. --Boundary_(ID_TtNmBq8oWER+YptliaSLaA) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 8BIT   Divining for offense is a popular pastime these days so the fact that someone somewhere was offended by an IETF backronym should surprise absolutely no one. This really took off when the definition of offense changed from intention of the speaker to how the recipient felt about it and being offended started to be used as a cudgel. It's basically a power-grab-- I take offense at your words and you must now grovel to my satisfaction.   I think the best course of action is to ignore the offended (telling them to get a life may be helpful or may inflame them, it depends). They will soon go looking for other greener pastures and people who will react to their demands. The reputation of the IETF will be fine.   Dan. On 1/10/22 1:41 PM, Phillip Hallam-Baker wrote: > Choosing to apply a silly name to yourself is not the same as choosing > an insulting name and applying it to other people. > > I object to the use of the terms 'SJW' and 'NeoCon' to refer to people > who have never referred to themselves as such precisely because the > intention is to insult and demean. It is argument by name calling. > > As it happens, I was not the target of RFC 3424 and it would have been > pretty brave of the editor to have put her name to it if I had been > the target since we both worked for the same company at the time. The > reason I am raising it is that the conversations I am seeing in > another place and the off-list follow-ups make it very clear that a > lot of people were offended and it is very clearly damaging to the > reputation of the IETF. > > > > > On Mon, Jan 10, 2022 at 2:46 PM Dan Harkins wrote: > > >   I'm really sorry this is happening to you PHB. > >   The thing is, I remember back in the late 90s and early aughts > when the > attitude on NAT was, roughly, "if you NAT the 'net you're not on > the 'net", > or something like that. There was lots of pushback to discount any > security > that people pushing NATs claimed. It was the popular sentiment at > the time, > NATs do not provide security. > >   So they chose a cutesy acronym. You're right that it's childish > but you're > wrong that it's bullying. Lots of IETF acronyms are childish. Look > at kitten. > Even now we have a sedate WG. There's a long history of these > sorts of acronyms > in the IETF. > >   If you want to start a campaign to eliminate cutesy and childish > acronyms > in the IETF then I wish you luck. But leave RFC 3424 alone. This > is why I was > so against the whole terminology push to begin with. It would > never stop with > just "blacklist" or "master/slave", there would have to be a > continual stream > of documents/terms that would need to be addressed to justify the > effort. > The inquisition will have to close if its scope isn't continually > expanded. > Better to not start it in the first place. > >   Dan. > > On 1/10/22 5:23 AM, Phillip Hallam-Baker wrote: >> The acronym plays absolutely no role in the document other than >> repeatedly referring to a set of technologies they dislike as UNSAFE. >> >> Let’s call that a CHLDSH acronym. The problem with reading a >> paper with a CHLDSH acronym document is that all the time you are >> reading the arguments you are thinking about the tactic of being >> CHLDSH instead of what the document is supposedly about. >> >> I find the document next to impossible to follow because the term >> really isn’t well defined except as ‘mechanisms trying to do >> something we oppose on principle’. >> >> It’s like reading a paper that keeps shouting UNCLEAN! UNCLEAN! >> >> Looking at the paper, it is making me think that a lot of IETF >> argument consists of picking a random position and insisting it >> is the right one because it is the position that all right >> thinking people believe. Then suggesting anyone who is >> challenging this random position is the person ‘being difficult’. >> >> The point is that the paper is 1) showing disrespect to people >> holding an opposed technical position and 2) repeatedly saying, >> ‘hey look at us, we are the IAB, we can show disrespect and you >> have to like it’. >> >> Yuk >> >> >> Get Outlook for iOS >> ------------------------------------------------------------------------ >> *From:* Mirja Kuehlewind >> >> *Sent:* Monday, January 10, 2022 6:28:02 AM >> *To:* Phillip Hallam-Baker >> >> *Cc:* terminology@ietf.org >> ; IAB IAB >> >> *Subject:* Re: [Terminology] We should avoid childish acronyms as >> well >> Hi PHB, >> >> Thanks for flagging the discussion below. I agree that we have to >> be careful when selecting acronyms and in the IESG there are >> often discussions about picking appropriate acronyms for working >> group which are on the one hand meaningful but also don’t suggest >> a wrong associations or even harass anybody. This is quite hard >> and sometimes we get it wrong. >> >> For RFC3424, even if we can argue about the acronym (and please >> note that the mechanisms discussed are not NAT itself but >> mechanisms that have been developed to circumvent any unintended >> consequences of NAT), I don’t follow you argument that this >> document "is completely unprofessional and should never have been >> published” and as such also don’t see that making it >> historic would be adequate. >> >> Also note that the status historic is used for specification >> with have "been superseded by a more recent specification or is >> for any other reason considered to be obsolete” (RFC2026). Not >> sure how to apply this to an IAB document. Also note that IAB >> documents are not IETF-consensus documents but merely >> documents that provide guidance to the community form the IAB at >> that time. >> >> Mirja >> >> >> >>> On 10. Jan 2022, at 02:07, Phillip Hallam-Baker >>> wrote: >>> >>> (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) >>> >>> >>> >>> Peter Gutmann >>> >>> >>> >>> Thu, Jan 6, 11:31 PM (3 days ago) >>> >>> >>> >>> to *Peter*, Phillip, R, Cryptography >>> >>> Phillip Hallam-Baker 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. >>> -- >>> Terminology mailing list >>> Terminology@ietf.org >>> https://www.ietf.org/mailman/listinfo/terminology >> >> > > -- > "The object of life is not to be on the side of the majority, but to > escape finding oneself in the ranks of the insane." -- Marcus Aurelius > > -- > Terminology mailing list > Terminology@ietf.org > https://www.ietf.org/mailman/listinfo/terminology > > -- "The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane." -- Marcus Aurelius --Boundary_(ID_TtNmBq8oWER+YptliaSLaA) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 8BIT
  Divining for offense is a popular pastime these days so the fact
that someone somewhere was offended by an IETF backronym should surprise
absolutely no one. This really took off when the definition of offense
changed from intention of the speaker to how the recipient felt about
it and being offended started to be used as a cudgel. It's basically a
power-grab-- I take offense at your words and you must now grovel to
my satisfaction.

  I think the best course of action is to ignore the offended (telling
them to get a life may be helpful or may inflame them, it depends). They
will soon go looking for other greener pastures and people who will
react to their demands. The reputation of the IETF will be fine.

  Dan.

On 1/10/22 1:41 PM, Phillip Hallam-Baker wrote:
Choosing to apply a silly name to yourself is not the same as choosing an insulting name and applying it to other people.

I object to the use of the terms 'SJW' and 'NeoCon' to refer to people who have never referred to themselves as such precisely because the intention is to insult and demean. It is argument by name calling.

As it happens, I was not the target of RFC 3424 and it would have been pretty brave of the editor to have put her name to it if I had been the target since we both worked for the same company at the time. The reason I am raising it is that the conversations I am seeing in another place and the off-list follow-ups make it very clear that a lot of people were offended and it is very clearly damaging to the reputation of the IETF.





  I'm really sorry this is happening to you PHB.

  The thing is, I remember back in the late 90s and early aughts when the
attitude on NAT was, roughly, "if you NAT the 'net you're not on the 'net",
or something like that. There was lots of pushback to discount any security
that people pushing NATs claimed.
It was the popular sentiment at the time,
NATs do not provide security.

  So they chose a cutesy acronym. You're right that it's childish but you're
wrong that it's bullying. Lots of IETF acronyms are childish. Look at kitten.
Even now we have a sedate WG. There's a long history of these sorts of acronyms
in the IETF.

  If you want to start a campaign to eliminate cutesy and childish acronyms
in the IETF then I wish you luck. But leave RFC 3424 alone. This is why I was
so against the whole terminology push to begin with. It would never stop with
just "blacklist" or "master/slave", there would have to be a continual stream
of documents/terms that would need to be addressed to justify the effort.
The inquisition will have to close if its scope isn't continually expanded.
Better to not start it in the first place.

  Dan.

On 1/10/22 5:23 AM, Phillip Hallam-Baker wrote:
The acronym plays absolutely no role in the document other than repeatedly referring to a set of technologies they dislike as UNSAFE.

Let’s call that a CHLDSH acronym. The problem with reading a paper with a CHLDSH acronym document is that all the time you are reading the arguments you are thinking about the tactic of being CHLDSH instead of what the document is supposedly about.

I find the document next to impossible to follow because the term really isn’t well defined except as ‘mechanisms trying to do something we oppose on principle’.

It’s like reading a paper that keeps shouting UNCLEAN! UNCLEAN!

Looking at the paper, it is making me think that a lot of IETF argument consists of picking a random position and insisting it is the right one because it is the position that all right thinking people believe. Then suggesting anyone who is challenging this random position is the person ‘being difficult’.

The point is that the paper is 1) showing disrespect to people holding an opposed technical position and 2) repeatedly saying, ‘hey look at us, we are the IAB, we can show disrespect and you have to like it’.

Yuk


From: Mirja Kuehlewind <ietf@kuehlewind.net>
Sent: Monday, January 10, 2022 6:28:02 AM
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: terminology@ietf.org <terminology@ietf.org>; IAB IAB <iab@iab.org>
Subject: Re: [Terminology] We should avoid childish acronyms as well
 
Hi PHB,

Thanks for flagging the discussion below. I agree that we have to be careful when selecting acronyms and in the IESG there are often discussions about picking appropriate acronyms for working group which are on the one hand meaningful but also don’t suggest a wrong associations or even harass anybody. This is quite hard and sometimes we get it wrong.

For RFC3424, even if we can argue about the acronym (and please note that the mechanisms discussed are not NAT itself but mechanisms that have been developed to circumvent any unintended consequences of NAT), I don’t follow you argument that this document "is completely unprofessional and should never have been published” and as such also don’t see that making it historic would be adequate.

Also note that the status historic is used for specification with have "been superseded by a more recent specification or is for any other reason considered to be obsolete” (RFC2026). Not sure how to apply this to an IAB document. Also note that IAB documents are not IETF-consensus documents but merely documents that provide guidance to the community form the IAB at that time.

Mirja



On 10. Jan 2022, at 02:07, Phillip Hallam-Baker <phill@hallambaker.com> wrote:

(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.


Peter Gutmann pgut001@cs.auckland.ac.nz


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


to PeterPhillipRCryptography
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.
--
Terminology mailing list
Terminology@ietf.org
https://www.ietf.org/mailman/listinfo/terminology



-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius
--
Terminology mailing list
Terminology@ietf.org
https://www.ietf.org/mailman/listinfo/terminology


-- 
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius
--Boundary_(ID_TtNmBq8oWER+YptliaSLaA)-- From nobody Mon Jan 10 14:50:52 2022 Return-Path: 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 753633A1432 for ; Mon, 10 Jan 2022 14:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham 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 G_5J9jzvdc-M for ; Mon, 10 Jan 2022 14:50:47 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0C93A1430 for ; Mon, 10 Jan 2022 14:50:47 -0800 (PST) Received: from xse.mail2web.com ([66.113.192.6]) by mx133.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1n73Uv-000AlH-Pc for terminology@ietf.org; Mon, 10 Jan 2022 23:50:43 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4JXpvN3fkrzNwg for ; Mon, 10 Jan 2022 14:50:40 -0800 (PST) Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1n73Uu-0001sn-CX for terminology@ietf.org; Mon, 10 Jan 2022 14:50:40 -0800 Received: (qmail 4760 invoked from network); 10 Jan 2022 22:50:39 -0000 Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.84]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 Jan 2022 22:50:39 -0000 Message-ID: Date: Mon, 10 Jan 2022 12:50:37 -1000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: Dan Harkins , terminology@ietf.org References: <11986BE7-1C65-49F8-8615-2A622C6B311E@kuehlewind.net> <389f5791-14b8-1a91-77fc-1a86048ab5cf@lounge.org> From: Christian Huitema In-Reply-To: <389f5791-14b8-1a91-77fc-1a86048ab5cf@lounge.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: 66.113.192.6 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.192.0/27 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.192.0/27@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x7S04AQt6808pfyoVHXMdQVjVx0XVkNnHJMw/amoreOT6R B2EHSwPlPKXZlp4audyrAP5R/Cae/ZemygD++WnmSxIRXVMlFuiz/acFNeeXtxN2fFxZWB9eYgpR BRu3UlDHMLIJYRi1cXH9Dbm+IxLVPhu0JUfebgEzWkJ+afQTfpotTbzF8bFslzcWfB/84WX1KHe/ FVcvFYE7DSY4uAuvkVWClPVvbW5lVyQanRxw5hTHswbbB/ha+ZWrSAi8SkwqWAikMcSxTAWn8RCv ieGEqjG/gXZAaRh1X6LVetRf2ZYIiHqfCgG4wrA3w4/kQTYKxDHA9JN9J4k4XZq11JQkgOaZXY1D 3Tei6L4lTC3Kzv6blagzf/fouhj8KehojfmLb5mum9xAXSaS3KKPtTZXWZip9+GhedmPokL8D3vh veYLhIg92+wH02ylfDiSQ0sYFBl6VX84fRovDGikEvLu7vlxwPg5iSJU22qtYbc2zIvhSJcbnX/H QqL/X9rNCJCc6iESJvKm1NV8gkr+Wu8ScVDXinOVyuIpITQ9z3M3DCinc6hm4Yij/9/ori/8mFV4 V97ui3VA1OEF+KxGdWeoiPi3z9emciOhkVFDj3DagCiEN91HYfCW+kSg4KAHI8HL3VJD2rnYxsyB Wmc9JBgRrnX8DAxpkCYbCO495zH8cQFVnde1UJCYLdcfX0Bx8d3C3+XDgfv5eKilgYPVmyd91wrq tplqj12FE5hu/LdV45vnsZNVCi9h56BdcRVvgJBaQLAY4Ohxvocfr2qxK3eoZuM7jUXIESohoO51 xWmU8ZWl4WzxEKtlYIkiBBvn+Cx8mz6/+51ry19BcG4FkCAMpuzLPc2VvAqe6FQiaiKH0BjKjv1P 4OTNlksev6kNmdNBFNa0IY/JLHAmsnKl/dxe8AUy9furwzjHps/+CPPDQ++QLcvZOcS+BJG+m3Ce FykYp15CIK9zGJHbSMTxEpqbZAkeAc5FoBC3+rm7DidFTvY4ocfmWv3Fe9Iziczdq+A= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 22:50:51 -0000 On 1/10/2022 9:46 AM, Dan Harkins wrote: >   The thing is, I remember back in the late 90s and early aughts when the > attitude on NAT was, roughly, "if you NAT the 'net you're not on the > 'net", > or something like that. There was lots of pushback to discount any > security > that people pushing NATs claimed. It was the popular sentiment at the > time, > NATs do not provide security. "The IAB hated NATs" makes for a cure meme, but as far as I remember, this was NOT the motivation behind the so called "UNSAF" requirements. If you read RFC, the text point out limitations such as dealing with multiple layers of NAT, and the general complexity of the mechanisms. It also says "By circumventing the NAT, UNSAF mechanisms may also (inadvertently) circumvent security mechanisms", which is as close as it gets from endorsing NAT as a security tool. -- Christian Huitema From nobody Tue Jan 11 09:43:35 2022 Return-Path: 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 1ADD13A0C0A for ; Tue, 11 Jan 2022 09:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.496 X-Spam-Level: X-Spam-Status: No, score=-0.496 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham 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 MTaUvIg20USf for ; Tue, 11 Jan 2022 09:43:31 -0800 (PST) Received: from www1.webmail.pair.com (www1.webmail.pair.com [209.68.6.94]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6932B3A0C07 for ; Tue, 11 Jan 2022 09:43:31 -0800 (PST) Received: from rc.webmail.pair.com (localhost [127.0.0.1]) by www1.webmail.pair.com (Postfix) with ESMTP id ADDAB1A1062; Tue, 11 Jan 2022 12:43:29 -0500 (EST) MIME-Version: 1.0 Date: Tue, 11 Jan 2022 12:43:29 -0500 From: reynolds@cogitage.pairsite.com To: Dan Harkins Cc: terminology@ietf.org In-Reply-To: <538e446e-1624-f517-fba0-c8ca4674d522@lounge.org> References: <11986BE7-1C65-49F8-8615-2A622C6B311E@kuehlewind.net> <389f5791-14b8-1a91-77fc-1a86048ab5cf@lounge.org> <538e446e-1624-f517-fba0-c8ca4674d522@lounge.org> Message-ID: X-Sender: reynolds@cogitage.pairsite.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2022 17:43:34 -0000 On 2022-01-10 17:20, Dan Harkins wrote: > Divining for offense is a popular pastime these days so the fact > that someone somewhere was offended by an IETF backronym should > surprise > absolutely no one. This really took off when the definition of offense > changed from intention of the speaker to how the recipient felt about > it and being offended started to be used as a cudgel. It's basically a > power-grab-- I take offense at your words and you must now grovel to > my satisfaction. . . . "Sticks and stones may break my bones, but names will never hurt me." used to be a long-established cultural tool available in cases like these at issue. Useful to help all sides of an issue maintain calmness and rationaliy, but I have not seen it being used lately. Tom From nobody Tue Jan 11 12:05:16 2022 Return-Path: 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 D9BDE3A10A0 for ; Tue, 11 Jan 2022 12:05:14 -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 Qkampihus8Eg for ; Tue, 11 Jan 2022 12:05:10 -0800 (PST) Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) (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 67CF33A109D for ; Tue, 11 Jan 2022 12:05:10 -0800 (PST) Received: by mail-yb1-f169.google.com with SMTP id p187so357189ybc.0 for ; Tue, 11 Jan 2022 12:05:10 -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:references:in-reply-to:from:date :message-id:subject:to:cc; bh=seiJSYHvU4HQ5vyCVWlBxksy2X9nXNRD31sKfyLMCA4=; b=hJ8UI5f5YZRIlSi5njmgp31P2mTwyY8rFIUVNH7Qi2KxZ1n8tipNN8wIB3BF4ngjqP AUDfVPhG4QzK+MuiAmDYYRfjOVK5J+2mBOxt4aayiuRpMc4p4LjG2KfWj5QjZMXOzZ1C W0E6Si03cPsUBnxeVVUit5ssqy4X1SMARsLR2DCNMW+LNeh1M5336biWr+WcBCgLmtd3 h9UhZQS7RymWsq1rfqR+rIB34Bc+a9wtbrQ984V1ihErbbXZYHpwmEMKPtROsVd39i69 SbYcgUrpY5byKU5Tr2XN9elPd3oTYRj+kqf0/6V0ZpmibePsA30CxhevN/c/6hvUckZR Xc/A== X-Gm-Message-State: AOAM5307yXMEa8y4JTXyXigN4wIYVEGLYHNqKRq7gwsLOV341cBTpnoN S6nYbi94sBjBGblmtYwO+Wzvylkdv6SBte649vbul1lu X-Google-Smtp-Source: ABdhPJzfaeF8czBaF8gXwW3MLcmwqz9l/uiMeSy41lOzFGRSjjeInxbf/1VXoGCD/0cqqir4HQOtvQPPBav0jeSGKrw= X-Received: by 2002:a25:a4e9:: with SMTP id g96mr8374827ybi.19.1641931509516; Tue, 11 Jan 2022 12:05:09 -0800 (PST) MIME-Version: 1.0 References: <11986BE7-1C65-49F8-8615-2A622C6B311E@kuehlewind.net> <389f5791-14b8-1a91-77fc-1a86048ab5cf@lounge.org> <538e446e-1624-f517-fba0-c8ca4674d522@lounge.org> In-Reply-To: From: Phillip Hallam-Baker Date: Tue, 11 Jan 2022 15:04:56 -0500 Message-ID: To: reynolds@cogitage.pairsite.com Cc: Dan Harkins , terminology@ietf.org Content-Type: multipart/alternative; boundary="0000000000005ed49d05d553f849" Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2022 20:05:15 -0000 --0000000000005ed49d05d553f849 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 11, 2022 at 12:43 PM wrote: > On 2022-01-10 17:20, Dan Harkins wrote: > > Divining for offense is a popular pastime these days so the fact > > that someone somewhere was offended by an IETF backronym should > > surprise > > absolutely no one. This really took off when the definition of offense > > changed from intention of the speaker to how the recipient felt about > > it and being offended started to be used as a cudgel. It's basically a > > power-grab-- I take offense at your words and you must now grovel to > > my satisfaction. > . . . > > "Sticks and stones may break my bones, but names will never hurt me." > used > to be a long-established cultural tool available in cases like these at > issue. Useful to help all sides of an issue maintain calmness and > rationaliy, > but I have not seen it being used lately. > > Tom > Victim blaming is of course a very convenient approach, if someone is offended you can dismiss them for being weak and unworthy. If they were not the person offended you can ask why they are making a fuss. So you can defend people being obnoxious by mocking people who suggest being obnoxious is wrong. The whole point of this group is to avoid giving unintended offense. But the argument you are making lacks understanding of just how powerful social peer pressure can be and how it is abused to suppress dissent. If you look at the information engagement literature you will discover that the Tudor monarchs popularized 'Irish jokes' as part of a campaign to justify the invasion of Ireland. If you watch rallies by mid 20th century dictators, you will find they spend quite a lot of their time making insulting and derogatory comments about their opponents. The reason Trump has lost his hold on US politics outside his party is not that he doesn't have access to Twitter, it is because the establishment media refuses to repeat his demeaning attacks on his opponents. --0000000000005ed49d05d553f849 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jan 11, 2022 at 12:43 PM <reynolds@cogit= age.pairsite.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On 2022-01-10 17:20, Dan H= arkins wrote:
> Divining for offense is a popular pastime these days so the fact
> that someone somewhere was offended by an IETF backronym should
> surprise
> absolutely no one. This really took off when the definition of offense=
> changed from intention of the speaker to how the recipient felt about<= br> > it and being offended started to be used as a cudgel. It's basical= ly a
> power-grab-- I take offense at your words and you must now grovel to > my satisfaction.
. . .

"Sticks and stones may break my bones, but names will never hurt me.&q= uot;
used
to be a long-established cultural tool available in cases like these at
issue.=C2=A0 Useful to help all sides of an issue maintain calmness and rationaliy,
but I have not seen it being used lately.

Tom

Victim blaming is of course a very convenient approach= , if someone is offended you can dismiss them for being weak and unworthy. = If they were not the person offended you can ask why they are making a fuss= . So you can defend people being obnoxious=C2=A0by mocking people who sugge= st being obnoxious is wrong.


The whole point of this group = is to avoid giving unintended offense. But the argument you are making lack= s understanding of just how powerful social peer pressure can be and how it= is abused to suppress dissent.

If you look at the information engagement literature you will discov= er that the Tudor monarchs popularized 'Irish jokes' as part of a c= ampaign to justify the invasion of Ireland.

If you watch rallies by mid 20th century dictators, yo= u will find they spend quite a lot of their time making insulting and derog= atory comments about their opponents. The reason Trump has lost his hold on= US politics outside his party is not that he doesn't have access to Tw= itter, it is because the establishment media refuses to repeat his demeanin= g attacks on his opponents.





=C2=A0
--0000000000005ed49d05d553f849-- From nobody Sun Jan 16 17:17:20 2022 Return-Path: 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 E71593A137F for ; Sun, 16 Jan 2022 17:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 eswuTmh7-sW5 for ; Sun, 16 Jan 2022 17:17:13 -0800 (PST) Received: from www3.webmail.pair.com (www3.webmail.pair.com [66.39.3.34]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F0D63A13C9 for ; Sun, 16 Jan 2022 17:17:13 -0800 (PST) Received: from rc.webmail.pair.com (localhost [127.0.0.1]) by www3.webmail.pair.com (Postfix) with ESMTP id 8A33A149731; Sun, 16 Jan 2022 20:17:11 -0500 (EST) MIME-Version: 1.0 Date: Sun, 16 Jan 2022 20:17:11 -0500 From: reynolds@cogitage.pairsite.com To: Phillip Hallam-Baker Cc: terminology@ietf.org, reynolds@cogitage.pairsite.com In-Reply-To: References: <11986BE7-1C65-49F8-8615-2A622C6B311E@kuehlewind.net> <389f5791-14b8-1a91-77fc-1a86048ab5cf@lounge.org> <538e446e-1624-f517-fba0-c8ca4674d522@lounge.org> Message-ID: X-Sender: reynolds@cogitage.pairsite.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2022 01:17:18 -0000 On 2022-01-11 15:04, Phillip Hallam-Baker wrote: > On Tue, Jan 11, 2022 at 12:43 PM > wrote: > >> On 2022-01-10 17:20, Dan Harkins wrote: . . . >>> It's basically a power-grab-- I take offense at your words and >>> you must now grovel to my satisfaction. >> . . . >> >> "Sticks and stones may break my bones, but names will never hurt me." >> used to be a long-established cultural tool available in cases like >> these >> at issue. Useful to help all sides of an issue maintain calmness and >> rationaliy, but I have not seen it being used lately. >> >> Tom > > Victim blaming is of course a very convenient approach, if someone is > offended you can dismiss them for being weak and unworthy. If they > were not the person offended you can ask why they are making a fuss. > So you can defend people being obnoxious by mocking people who suggest > being obnoxious is wrong. > > The whole point of this group is to avoid giving unintended offense. > But the argument you are making lacks understanding of just how > powerful social peer pressure can be and how it is abused to suppress > dissent. > > If you look at the information engagement literature you will discover > that the Tudor monarchs popularized 'Irish jokes' as part of a > campaign to justify the invasion of Ireland. > > If you watch rallies by mid 20th century dictators, you will find they > spend quite a lot of their time making insulting and derogatory > comments about their opponents. The reason Trump has lost his hold on > US politics outside his party is not that he doesn't have access to > Twitter, it is because the establishment media refuses to repeat his > demeaning attacks on his opponents. I respectfully disagree with your assertion "the argument you are making lacks understanding". It is just because I quite understand social forces (and sociolinguistics) that I brought up the cultural tool I quoted in my Jan 11, 2022 post. "Wise sayings" used to arise, and to be widely practiced or not, as the result of many social interactions over long time periods. I think this maxim is (or was before electronic social media chaff confused so much cultural wisdom) successful because it is a solid middle ground one, useful in many kinds of situations. With the first phrase, insulting personages are chided that they have been attacking the utterer of the maxim; with the second phrase the utterer indicates he/she will not be intimidated even if physically attacked. And by displaying exemplary behavior--ie saying the maxim instead of bashing the insulter with a stick--the utterer is offering a behavioral standard for the insulter to adopt. Separately, there are pretty well known examples of dictators and politicians gaining support by falsely claiming having been harmed. Eg Hitler's claim that Germany's boundaries had been shamefully reduced; or the current claim in the USA that the last election was shamefully stolen, used to motivate supporters to try to steal the election on behalf of their candidate. A useful practice in the terminology/RFC arena is the baseline rule to listen to anyone making a claim, and do it long enough to judge what they say. This facilitates getting enough data to begin to evaluate the character of the people involved, and to judge sincerity. This Terminology group and RFC development in general seem to me to be good examples of "listening to anyone long enough". Which makes me curious whether there been any sociological studies of the RFC process which could be referred to in thinking about the terminology issue(s) at hand? Tom