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

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 9 Jan 2022 20:07:51 -0500

(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 <[email-masked]>

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

to *Peter*, Phillip, R, Cryptography
Phillip Hallam-Baker <[email-masked]> 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.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 10 Jan 2022 12:28:02 +0100

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 <[email-masked]> wrote:
> 
> 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 <[email-masked] <mailto:[email-masked]>>
> 
> 
> to Peter, Phillip, R, Cryptography
> 
> Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]>> 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".
> 
> at RFC 3424 for example, which invented a childish backronym "UNSAF" to refer
> levels of self-flagellation that any UNSAF mechanism is required by the IAB to
> subject itself to.
> 
> Peter.
> -- 
> Terminology mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/terminology

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 10 Jan 2022 13:23:48 +0000

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 <[email-masked]>
Sent: Monday, January 10, 2022 6:28:02 AM
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked] <[email-masked]>; IAB IAB <[email-masked]>
Subject: Re: [Terminology] We should avoid childish acronyms as well

Hi PHB,

Mirja

On 10. Jan 2022, at 02:07, Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>> wrote:

[Cryptography] Two quick questions about IPsec AH (metzdowd.com)<https://www.metzdowd.com/pipermail/cryptography/2022-January/037663.html>
Peter Gutmann <[email-masked]<mailto:[email-masked]>>

[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]

Peter.
--
Terminology mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/terminology

---

From: Dan Harkins <[email-masked]>
Date: Mon, 10 Jan 2022 11:46:32 -0800

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’.
>
> 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 <[email-masked]>
> *Sent:* Monday, January 10, 2022 6:28:02 AM
> *To:* Phillip Hallam-Baker <[email-masked]>
> *Cc:* [email-masked] <[email-masked]>; IAB IAB <[email-masked]>
> *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
>
>
>
>> 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.
>>
>>

-- 
"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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 10 Jan 2022 16:41:42 -0500

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 <[email-masked]> wrote:

> in the IETF then I wish you luck. But leave RFC 3424 alone. This is why I
> was
> 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’.
>
> 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 <[email-masked]> <[email-masked]>
> *To:* Phillip Hallam-Baker <[email-masked]> <[email-masked]>
> *Cc:* [email-masked] <[email-masked]> <[email-masked]>;
> IAB IAB <[email-masked]> <[email-masked]>
> 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
>
>
>
> 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.
>

---

From: Dan Harkins <[email-masked]>
Date: Mon, 10 Jan 2022 14:20:12 -0800

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.
>
> 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.
>
>
>
>
>       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.
>
>     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
>>     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
>>     really isn’t well defined except as ‘mechanisms trying to do
>>     something we oppose on principle’.
>>
>>     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
>>
>>
>>     <mailto:[email-masked]>
>>     <mailto:[email-masked]>
>>     *Cc:* [email-masked] <[email-masked]>
>>     <mailto:[email-masked]>; IAB IAB <[email-masked]>
>>     <mailto:[email-masked]>
>>     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
>>     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
>>
>>
>>
>>>     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.
>>>
>>>     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.
>>>
>>>

---

From: Christian Huitema <[email-masked]>
Date: Mon, 10 Jan 2022 12:50:37 -1000

> 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: [email-masked]
Date: Tue, 11 Jan 2022 12:43:29 -0500

> power-grab-- I take offense at your words and you must now grovel to
. . .

"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: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 11 Jan 2022 15:04:56 -0500

> but I have not seen it being used lately.

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.

---

From: [email-masked]
Date: Sun, 16 Jan 2022 20:17:11 -0500

. . .
>>> It's basically a power-grab-- I take offense at your words and
>>> you must now grovel to my satisfaction.
>> . . .
>> 
>> 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
> 
> 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.
> 
> 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