Re: IESG Statement On Oppressive or Exclusionary Language

["Joel M. Halpern" <[e-mail]>]

It seems to me that the first place to do this is in I-Ds, even if we do 
not have strict enforcement mechanisms.  And if it is to be done in 
I-Ds, it is up to the individual streams to do so.  Having the IETF 
discuss doing this for IETF i_Ds seems a really effective and sensible 
starting point.

Yours,
Joel

On 7/23/2020 2:31 PM, Michael StJohns wrote:
> 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
>>
>>
>