Re: IESG Statement On Oppressive or Exclusionary Language

[Michael StJohns <[e-mail]>]

On 7/23/2020 2:20 PM, 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:[e-mail]>> wrote:
>>
>>         Hi -
>>
>>         I support the general goals you've stated below, but I have a
>>         few problems with how you're (IESG) suggesting we approach
>>         them. Two in particular:
>>
>>         1) The onus for implementing whatever we end up deciding will
>>         be on the RFC Editor and the RPC - that argues that the
>>         primary driver of the language effort should be rooted over
>>         on the rfc-interest mailing list, and driven by the RSE (or
>>         the temporary equivalent) and not as part of the general
>>         area.  I'm not sure why this even needs to run past Dispatch?
>>
>>
>>     For what it's worth, I disagree with this.  The primary mode of
>>     implementation here for new work will be a change in community
>>     practice, not a set of changes implemented at the end of the
>>     process by the RSE or RPC.  It also seems to clear to me that it
>>     would be valuable for the other streams to consider the same
>>     issues, but I don't believe that changing the IETF's practice
>>     requires the consensus of the other streams to change.
>
>     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.

Note the above does not say "IETF Stream Authors SHOULD".


>
> 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.

I don't disagree with the first or second sentence, but this is not an 
IETF Stream nor an IAB Stream nor an IRTF Stream nor an Independent 
Stream issue, but a community issue directly related to the publication 
of RFCs.  If you set requirements for the RFCs, they flow back into the 
submissions from the streams.

This is not a IETF BCP issue - except as the RFC style guide might be 
adopted as a BCP.  E.g an update to RFC7322.

Later, Mike

>
> Adjustment of the language of the draft to reflect that targeting 
> would, of course, be fine by me.
>
> regards,
>
> Ted Hardie
>
>