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

Hard to comment on your primary example as you were (understably) 
somewhat vague.

With regard to the multicast case, "Underlay" would have been a better 
term than "Native" in the original case, and would still be a better 
term now.

Most cases where I see folks writing "using native X', "native" is not 
actually a clear term and we would be better of for our own clarity to 
avoid the term.

Yours,

Joel

On 9/12/2022 2:21 PM, Toerless Eckert wrote:
> 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).
>
> _______________________________________________
> rfc-interest mailing list
> rfc-interest@rfc-editor.org
> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest