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.
> 
> 
> [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)
> 
> 
> 
> to Peter, Phillip, R, Cryptography
> 
> 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
> https://www.ietf.org/mailman/listinfo/terminology