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

[Phillip Hallam-Baker <[e-mail]>]

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