Re: IESG Statement On Oppressive or Exclusionary Language

[Fernando Gont <[e-mail]>]

Hi, Ted,

On 23/7/20 15:20, Ted Hardie wrote:
> On Thu, Jul 23, 2020 at 11:08 AM Michael StJohns <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     On 7/23/2020 1:54 PM, Ted Hardie wrote:
>>     Howdy,
>>
>>     On Thu, Jul 23, 2020 at 10:36 AM Michael StJohns
>>     <[e-mail] <mailto:mstjohns@comcast..net>> wrote:
>>
[....]
>     Hi -
> 
>     I'm actually surprised that you think its a good idea to do this on
>     a stream basis rather than on a community basis.   Regardless, the
>     draft cited is pretty clear that it wants to add constraints to the
>     RFC process:
> 
> Just above the text you cite is this:
> 
> Authors SHOULD: * Replace the excluding term "master-slave" with more
>     accurate alternatives, for instance from the list of Section 3.1.  *
>     Replace the excluding term "blacklist-whitelist" with more accurate
>     alternative, for instance from the list of suggested alternatives at
>     Section 3.2.  * Reflect on their use of metaphors generally * Use the
>     neutral "they" as the singular pronoun, and * Consider changing
>     existing exclusive language in current (reference) implementations
>     [socketwench] * Consult the style sheet maintained by the RFC editor.
> 
> 
> Getting the cultural shift to this reflection on the consideration means 
> that it will be rare that the RFC editor will need to offer 
> alternatives. It also means the language in I-Ds and working group 
> discussion will avoid the terms early, rather than expecting a 
> post-facto adjustment by an expert.  A BCP covering the IETF practice 
> here seems to me a useful thing to do, even if all the other streams 
> come to very similar practices.

If this is to be applied, why not apply it to all IETF contributions, 
rather than to some particular form of it?

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492