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

[Dan Harkins <[e-mail]>]

   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 <[e-mail]> 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 <https://aka.ms/o0ukef>
>>     ------------------------------------------------------------------------
>>     *From:* Mirja Kuehlewind <[e-mail]>
>>     <mailto:[e-mail]>
>>     *Sent:* Monday, January 10, 2022 6:28:02 AM
>>     *To:* Phillip Hallam-Baker <[e-mail]>
>>     <mailto:[e-mail]>
>>     *Cc:* [e-mail] <[e-mail]>
>>     <mailto:[e-mail]>; IAB IAB <[e-mail]>
>>     <mailto:[e-mail]>
>>     *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
>>>     <[e-mail]> 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 <[e-mail]>
>>>
>>>     	
>>>
>>>     Thu, Jan 6, 11:31 PM (3 days ago)
>>>
>>>     	
>>>     	
>>>     to *Peter*, Phillip, R, Cryptography
>>>
>>>     Phillip Hallam-Baker <[e-mail]> 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
>>>     [e-mail]
>>>     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
>     [e-mail]
>     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