Re: IESG Statement On Oppressive or Exclusionary Language

[Richard Barnes <[e-mail]>]

Hi Mike,

I think you're taking the wrong approach here.  I would suggest approaching
this from a frame of compassion / honest effort instead of one of
engineering.  What matters here is making a good-faith effort at
inclusiveness, not nailing down every corner case.

Looking at your points in that frame:

1. Let's not sweat the procedural details here.  It doesn't matter if the
RFC Editor / RPC has the specific right set of instructions, what matters
is that we the IETF request that they keep certain things in mind with
regard to our documents.  As a way to help us keep ourselves honest.

2. While I respect your commitment to academic rigor, the quality of the
citations is not the most important thing here.  There are several clear,
well-known examples cited in the paper and acted on in several other places
across the industry, which illustrate the general path we should be on.
Again, where exactly we land on "master boot record" is kind of secondary;
the point is that we make the meta commitment to looking out for situations
like this and trying to work through them.

Cheers,
--Richard



On Thu, Jul 23, 2020 at 1:36 PM Michael StJohns <[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?
>
> 2) I'm not enamored of the document [1] for a number of reasons:
>
>    - At least three of the sources  (BrodieGravesGraves, Burgest, Eglash)
>    are  behind paywalls making it difficult for anyone besides the authors to
>    do a meaningful review
>    - other sources appear to be paper only - at least there are no
>    on-line references
>    - there are few peer-reviewed scholarly papers referenced - it would
>    be helpful to have more to strengthen any arguments rather than depending
>    on popular press opinion pieces (Grewal, Jansens, McClelland)
>    - because X, Y and Z did it isn't a great set of arguments for why we
>    should do it (e.g, Drupal, Github, etc)
>    - If we're going to get into this, we need to also address "master" as
>    a stand-alone term, not simply in the context of "master/slave" - e.g.
>    "master copy", "mastering a recording", "zone master file", "mastering a
>    skill", "master controller".  I'd *really* like to not have to do this
>    multiple times because we lacked imagination or completeness.
>    - the list of master/slave alternatives within the document doesn't
>    really deal with the "controlling entity/controlled entity" pattern.
>
> Later, Mike
>
> On 7/23/2020 12:35 PM, The IESG wrote:
>
> The IESG believes the use of oppressive or exclusionary language is
> harmful.  Such terminology is present in some IETF documents, including
> standards-track RFCs, and has been for many years. It is at odds with
> our objective of creating an inclusive and respectful environment in the
> IETF, and among readers of our documents.
>
> The IESG realizes that the views of the community about this topic are
> not uniform. Determining an actionable policy regarding problematic
> language is an ongoing process. We wanted to highlight that initial
> discussions about this topic are taking place in the general area (a
> draft [1] is slated for discussion in GENDISPATCH [2] at IETF 108).
> Updating terminology in previously published RFCs is a complex endeavor,
> while making adjustments in the language used in our documents in the
> future should be more straightforward.
>
> The IESG looks forward to hearing more from the community, engaging in
> those discussions, and helping to develop a framework for handling this
> issue going forward.
>
> [1] https://datatracker.ietf.org/doc/draft-knodel-terminology/
> [2] https://www.ietf.org/proceedings/108/agenda/agenda-108-gendispatch-03
>
> _______________________________________________
> IETF-Announce mailing [e-mail]://www.ietf.org/mailman/listinfo/ietf-announce
>
>
>