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

[Stewart Bryant <[e-mail]>]

The DVB editors are happy with the term.

https://www.broadbandtvnews.com/2022/02/21/dvb-publishes-native-ip-over-dvb-specification-for-satellite-and-dtt/

Stewart

Sent from my iPad

> On 12 Sep 2022, at 19:21, Toerless Eckert <[e-mail]> 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).
>