Re: [Terminology] We should avoid childish acronyms as well

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<https://aka.ms/o0ukef>
________________________________
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<mailto: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.

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

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 <phill@hallambaker.com<mailto: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<mailto:Terminology@ietf.org>
https://www.ietf.org/mailman/listinfo/terminology