Re: IESG Statement On Oppressive or Exclusionary Language

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

Let me approach the quesiton of what i sneeded slightlhy differently.

Do you think the General AD has enough support / authority to ask the 
gen-art reviewers to look for problematic language?  If so, what should 
she point to as examples of what one might look for?  (The gen-art 
review team has people with a range of language backgrounds.)

Yours,
Joel

On 8/8/2020 11:48 PM, John C Klensin wrote:
> 
> 
> --On Saturday, August 8, 2020 22:42 -0400 "Joel M. Halpern"
> <[e-mail]> wrote:
> 
>> While full coordiantion probably needs something akin to RSE
>> involvement, it seems to me that it would be a useful step if
>> the IETF could at least figure out how to create a working
>> list along the lines of what Joe Touch posted.  (Here are some
>> words.  Here are some other words that you could / should /
>> might / ... consider using in place of them.)
>>
>> Having such a list with some resemblance of IETF rough
>> consensus that following it is a good idea would help us move
>> forward without getting bogged down in either "whose job is a
>> formal decision?" or "when will there be an RSE?".
>>
>> Such a list would, it seems to me, help genart reviewers at
>> least keep the question in mind.
> 
> Yes, but that takes me/us back to suggestions made weeks ago,
> i.e.,
> 
> (i) We treat this IESG statement and the underlying I-D as
> having done a great job of increasing the community's
> sensitivity to the issues of choices of language, largely
> independent or how those issues are defined.
> 
> (ii) We conclude that we really don't need to get to an official
> vocabulary, especially an official negative or discouraged
> vocabulary/ work list.
> 
> (iii) With the community's new-found sensitivity, we encourage
> document reviewers, especially within WGs in addition to IETF LC
> (or any particular review team) to spot unfortunate language as
> they read through documents.  When should language is spotted
> (again, preferably early in the document life cycle) it should
> lead to discussions with authors about whether the language is
> appropriate and possible alternative.  Reviews during IETF Last
> Call (or later) and public comments on the language should be
> viewed as a last resort although possibly a necessary one.
> 
>      john
> 
>