Re: IESG Statement On Oppressive or Exclusionary Language

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



While there are always risks in trying to guess how people will react to such things, I do not see it as likely.

For example, in replacing blacklist / whitelist with blocklist / permitlist (or similar terms) one actual gets clearer language that is closer to the intended meaning.

Similarly, in the discussion of DNS servers, it is pretty clear that the existing terms are not particularly good analogies for what is happening.

Yours,
Joel

PS: The lsit does not ahve to have just one alternative. For some / many of the terms being discussed, the better words will be different in the different places the older terms were used.

PPS: I am NOT proposing any effort to rewrite existing RFCs.

On 8/8/2020 11:20 PM, Loa Andersson wrote:
Joel,

Inline plese.

On 09/08/2020 10:42, Joel M. Halpern 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.)

I'm a bit reluctant to such a list, there is a risk that if the list
says instead of word 1 use word 2, we create a way of saying "word 1",
with another word, and over time the meaning will slowly change since
"everyone" know what was intended.

/Loa

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.

Yours,
Joel

On 8/8/2020 10:12 PM, John C Klensin wrote:


--On Saturday, August 8, 2020 13:52 -0400 Michael StJohns
<mstjohns@xxxxxxxxxxx> wrote:

Exactly.   This affects more than just the IETF, and any
result would have a stronger impact if agreed to by more than
just the IETF.  (To avoid doubt, I agree this is an RSE task).

On 8/8/2020 5:00 AM, Stewart Bryant wrote:
I disagree with this approach.

We should ask the RFC Series Editor to consult international
experts on technical language and the editors of other major
standards such as IEEE, ETSI and ITU and report back to us
with a recommendation.

Agreed, but with two suggestions/provisos (both derived from
comments made by others):

(1) Unless we want to push the IETF toward a relapse in which we
are a US-based body with some "foreigners" allowed to
participate, whatever mechanisms are developed need to be
sensitive to inappropriate terminology in other languages,
whether natively there, plausible translations, or
transliterations.  We don't need to boil all oceans all at once,
but we have to start with the understanding that US English is
not the only language or culture when inappropriate language
occurs.

(2) While I agree that this should be an RSE task, I think we
need to remember that we don't have an RSE.  While it might be
possible to ask John to start the research project (although
that is pushing the boundaries of what he signed up for) he
doesn't have, and it might be problematic to give him, the
authority to start making decisions in this space.  We should
also note that one reading of the trends in the RFC Futures
discussion (not, obviously, the only reading) is that we don't
really need an RSE, especially an RSE with any authority.  If
that was actually the trend in that area, then assigning this
type of responsibility to the RSE might be something of a
contradiction.

     john







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux