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

[Ronald Tse <[e-mail]>]

Google says it’s "built-in” or “{foo} first” but they don't fit this usage. I guess newspeak lookup tables don’t always work. Oops!

> On Sep 13, 2022, at 3:01 AM, Marc Petit-Huguenin <[e-mail]> wrote:
> 
> Another technical word has bitten the dust on the war on figurative usages.
> 
> (Oops, I meant "Another technical word has disappeared during the systematic elimination of figurative usages")
> 
> On 9/12/22 11:21, 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
>> [e-mail]
>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest
> 
> -- 
> Marc Petit-Huguenin
> Email: [e-mail]
> Blog: https://marc.petit-huguenin.org
> Profile: https://www.linkedin.com/in/petithug
> 
> _______________________________________________
> rfc-interest mailing list
> [e-mail]
> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest