[rfc-i] [rfc-interest] Concerned about lacking inclusive? word replacement process

[Toerless Eckert <[e-mail]>]

I am just in AUTH48 and being asked to replace the use of the word "native" with
something "less problematic".

 [ Excurse: I also had a significant run-in when using this
   word in a BoF @IETF114, especially in reference to a very common use of
   "native IP Multicast" that was created as a phrase around the use of IP Multicast
   in the 1990th to promote an evolution from an overlay network (MBone) to one where
   IP Multicast was running "natively" on the routers of the network (with PIM).
   And back then, we printed hundreds of t-shirt and mugs with that theme. 
   Now, i also got a great run-down of how even dangerous the use of the word "native"
   with any context may be in Africa these days (from Andrew Alston) unless you know you are
   entitled to use it - which typically you can assume you never are. ]

Now, my worries is that i looked through the use of "native <foobar>" in RFC
and found that out of 990 rfc8xxx.txt, 113 had occurrences of "native <foobar>",
wich a total number of 487 instances. For earlier and later blocks of 1000 RFC,
numbers are quite similar, and had peaked in rfc6???.txt (> 700 occurrences).

In other words: "native" is a crucial classifier for a lot of technical terms
that we use, used over long periods of time, and even if we changed any individual
instance now, anybody who would be looked for older documents use would still need
to know to look for "native". And worst yet: When you do know the old use of "native <foobar>",
and you try to find an equipment term that is "less problemativ" now, you are lost - because
we have no normative / recommended replacements for it. At least i am not aware of
any such tracking of replacements (please give me an IETF URL - please none of those
endless URL chains to other organizations that end nowhere!).

This lack of tracking of replacements and building consensus FOR OUR COMMUNITY
for as few as possible alternative replacments is IMHO a mayor IETF editorial
problem/challenge, and i do not understand why rfc-editor is not tackling this by
creating such a tracking for replacement terms.

On the basis of this problem not being tackled, i am of the belief that
as authors, one should resist asks for replacment words, in the hope that
this helps to elevate the problem so that RFC editor will better tackle this
replacemenet problem. 

Unless of course one does have as an author (or better yet of course as a WG)
a replacement term one is technically persuaded to be better. Which
in my case i didn't have in my last 2021 RFC where this problem occurred but
which i may have for my auth48 rfc now because i am referring to a new term
that the document makes up (more freedom of choosing a term).