Re: IESG Statement On Oppressive or Exclusionary Language

[John C Klensin <[e-mail]>]

Executive/ TL;DR Summary: Rather than looking for new mechanisms
or trying to see if we can build tools that are smarter than we
are, we will do far better for both the IETF community and the
Internet by expanding our existing document development and
review processes to include being as sensitive to inappropriate
vocabulary or presentation as we are to technical flaws.  The
issues are important and will often be difficult but, if we
cannot educate ourselves and each other to be able to deal with
them, any other attempted solutions are likely to cause worse
problems.



--On Tuesday, July 28, 2020 10:54 -0500 Nico Williams
<[e-mail]> wrote:

>...
> It would seem that evidence in this matter is important.
> Evidence of our having a problem would help drive faster
> adoption of better solutions.  Conversely, lack of evidence,
> or even evidence that we don't have a problem, would help us
> quickly dispose of solutions to non- problems.

And...

--On Tuesday, July 28, 2020 11:00 -0500 Nico Williams
<[e-mail]> wrote:

> I'm surprised not to find there anything like a survey of
> RFCs, current I-Ds, and maybe even expired I-Ds, of
> problematic language.  Or any analysis of the prevalence of
> problematic language and trends in its use.  Did we use to
> have a problem that we now no longer have?  Do we still have a
> problem?  Is it getting better or worse?
>...
> It would be quite useful to have such a survey.

I'm actually not sure about either of those assertions.  We know
that language -- and, more specifically, terminology-- has been
used in IETF documents and other Internet technical
specifications in the past that reasonable people can interpret
as having connotations that are problematic (including, but not
limited to, "Oppressive or Exclusionary").  Like Rich, I would
like to assume (and am convinced) that the vast majority of such
language was chosen out of ignorance or lack of sensitivity to
the possible issues and not out of some malicious intent or
explicit sense of superiority by the author toward other
populations.  

Should we do better at identifying such language in new
documents, bringing it to the attention of authors and, if
needed, the broader community?  I think so and I think that
would be true if we are talking about one incident a year or a
hundred incidents every week.   This is not one of those
subjects on which saying "well it doesn't happen often enough to
be a concern, so we should just move on" is reasonable, nor is
it one for which a larger volume of problematic language would
justify a radically different response.  And so I don't see what
more statistics would tell us that would be useful... other
than, maybe, promoting a large sense of outrage, something that,
IMO, is not useful if we are willing to engage with the problem
and that should not be needed for us to be willing to engage.

So, to repeat:  We should get better at encouraging people to
speak up when they spot problems of vocabulary or usage or even
tone that makes them uncomfortable (or other terms along that
scale).   Some explicit encouragement from the IESG and IAB
might be helpful in that regard; it almost certainly could not
hurt.   We should try to be sure that the community is as
supportive as possible when someone does raise such concerns,
possibly building on the ombudsteam mechanisms for dealing with
other types of inappropriate reactions in the community.  We
should try, as we should try with technical issues, quiet,
supportive, and educational private conversations with authors
and speakers rather than anything that amounts to public
shaming.  If that fails or is inappropriate, we should expect
WGs to detect and adjust the language of their drafts and, if
something slips through, to catch things on IETF Last Call.  If
documents with problematic language get through to the IESG, I
hope the IESG will catch those problems and push back but that
they will also examine why problems got through to them --how
things failed at earlier stages of the review process-- with an
eye toward looking at ways to preventing recurrences [1].

And I think we should be very careful to not create official
"bad vocabulary" lists or formal mechanisms to enforce them.  We
should also be careful that people don't set themselves up as
arbiters of what some other group would find offensive -- that
is ultimately either as demeaning of that other group and its
inability to speak up for itself or an indication that the IETF
has become toxic for that group in a way that discourages them
from speaking up.  The latter is not a problem about vocabulary
and, should it occur, our dealing with it effectively is
probably far more important than vocabulary issues.  That won't
solve the problem of vocabulary that might be offensive to
people from populations who have no presence in the IETF but, as
others have pointed out, the solutions to that lie in more
outreach and diversity rather than trying to narrow our language
to eliminate anything we think might be a problem for someone
else.

The other advantage of that approach -- simply expanding our
existing mechanisms for developing and reviewing documents
rather than inventing a new system or mechanism-- is that it is
also well-adapted to reasoned discussions about what to do about
language in older documents that we might object to today,
decisions that will certainly have to be made on a case by case
basis considering the disadvantages of trying to change
established usage. 

Of course, if we can't have reasoned and reasonable discussions
on these topics (again like technical ones) we either need to
educate people and fix that problem or we should consider
whether the IETF has outlived its usefulness.

Finally, I think we should thank the authors of the I-D and the
IESG for bringing the issue to our attention and stimulating
this discussion (regardless of what I think of the timing).  It
is just the solution to which the I-D seems to point that seems
entirely inappropriate for the IETF (and for any other body that
wants to be broadly and internationally sensitive to the broader
issues, not just a particular list of bad words.  If I am
misinterpreting the intent of either the authors (who have been
surprisingly quiet in this discussion) or the IESG, I apologize
and welcome corrections.

And now, having said that twice in different ways recently, I'm
going to retreat into trying to get other work, some of it
technical, done.

best regards and wishes to all,
   john


[1] Something we often (probably not often enough) tried to do
when I was on the IESG a quarter-century ago wrt technical
issues and that I think the IETF would be a better place if the
IESG were doing a lot more of now with technical issues as well
as choices of vocabulary or the like.  If we could view every
single issue that gets through IETF Last Call but is then
grounds for a DISCUSS in the IESG as a sign of a process failure
that the involved ADs are required to investigate and suggest
ways to prevent the next time, we'd see a more
smoothly-functioning IETF, fewer documents tied up for extended
periods after IETF Last Call, and probably even less generalized
rancor.

(Now we get to see who has read this far :-( )