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

[Marc Petit-Huguenin <[e-mail]>]

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