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

[Jean Mahoney <[e-mail]>]

Toerless,

On 9/12/22 6:31 PM, Toerless Eckert wrote:
> On Mon, Sep 12, 2022 at 03:17:04PM -0400, Joel Halpern wrote:
>> Hard to comment on your primary example as you were (understably) somewhat
>> vague.
> I just did not elaborate any further because i felt it would just derail more from my
> core point, which is that i would like IETF/RFC-editor to think about creating a tracking
> of old/bad/please-replace terms and their new/replacement terms.
[JM] The RPC recommends referring to the "Suggested Edits" column of 
Table 1 [1], which is pointed to in the NIST document from the IESG 
statement [2], rather than create a separate resource, as noted in the 
IESG statement, "Using the same terminology as other standards 
organizations and industry initiatives also contributes to overall 
coherence in the industry."

The replacement of a term is context dependent, and while we may make a 
suggestion, the RPC lets the authors choose. If an author declines to 
make updates, the RPC relies on the document's other AUTH48 participants 
to speak up if any changes are needed.

The current RPC guidance can be found in the Web Portion of the Style 
Guide [3].

Best regards,

Jean Mahoney
RPC Project Manager

[1] 
https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1
[2] https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/
[3] https://www.rfc-editor.org/styleguide/part2/#inclusive_language

>
> There was already another thread on rfc-editor, where some auto-glossary functions
> where discussed, and i raised the point as to whether or how to have a shared edited
> glossary. Such a glossary would be a great place to put such tracking into IMHO, and
> help WG and authors when writing drafts/picking terms, and when being in AUTH48.
>
>> 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.
> Except that "native IP multicast", and slogans such as "Go native" for it where
> (since the 90th) meant for use not in dry technical RFCs, but primarily in discussions
> with operators and non-technical users. Underlay is close enough to underwear to make any
> public use and derived terms (Go Underlay) at least borderline hilarious.
>
>> 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.
> So, we create a shared IETF glossary like we have our shared bibliography.
>
> When a draft introduces/uses some non-obvious technical term, WG/IETF review
> can ask to not only define that term in the drafts local glossary, but the
> dradfts/RFCs definition will also (ideally automatically) link into that shared
> IETF glossary.
>
> In result, reviewers can compare easily the glossary definitions of the same
> technical term across different drafts/RFCs. This can help to derive over time
> better an better glossary definitions of such terms creating more consistency. Or
> for bad marketing terms (such as "Intent"), one could easily unveil how
> a term is a widely differently used term and how then it is even more important
> for any document using such a term to be explicit about which definition of it,
> it refers to.
>
> That IMHO is highly useful whether or not a term is culturally problematic or not.
> And that shared glossary can be the basis for adding also such annotations such
> as new terms for existing glossary definitions, and of course tracking which
> draft/RFC uses which term for the same definition.
>
> Cheers
>      Toerless
>
>> 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
>>> [e-mail]
>>> https://mailman.rfc-editor.org/mailman/listinfo/rfc-interest