Re: [Gendispatch] draft charter text: terminology-related WG

[Stephen Farrell <[e-mail]>]

Hiya,

On 12/02/2021 01:24, Dan Harkins wrote:
> 
>    Howdy Stephen,
> 
> On 2/11/21 4:48 PM, Stephen Farrell wrote:
>>
>> Hi Dan,
>>
>> (Top quoting as this is just a question, but I know you care
>> about this and have also been active in IEEE...)
>>
>> Via mail to new-work/secdir today, I see that IEEE 802 (and
>> I've no idea if people are co-ordinating or not) seem to be
>> starting a fairly similar acctivity. [1]
> 
>    I was not aware of this. 

Me neither. Hence asking:-)

> Thanks for pointing it out >
>> My question is just: do you think the same about IEEE's
>> efforts, or is there any interesting difference?
> 
>    Yes, I would like to see IEEE 802.1 define "non-inclusive" and 
> "insensitive"
> before they go about requiring the replacement of terms. 

Ack, thanks.

> I will have to see
> about insisting on that.
> 
>    There was a back channel effort by an IESG member to get IEEE 802.11 to
> change the term "master key" in their standard and I put the kibosh on it
> because that is just blind substitution of words without thinking. A 
> "master
> key" is a term of art that derives from locksmithing. There is nothing
> insensitive about that term and it defies reason to say that some class of
> people have been excluded from locksmithing, and by inference will be 
> excluded
> from wi-fi, because this term was used.
> 
>    You seem to think I'm against these efforts. 

Well, I wasn't counting you as an enthusiast:-) As it happens
I think being skeptical is entirely fine, whilst I personally
think it's probably ok for us to do this.

I'm unsure if looking for definitions is a good way to try
constrain this or not. I suspect it's not, and that general
guidance and a few example improvements might be better.

> I'm not against making our
> documents more clear, more precise, and more accessible. 

Yep. I also think there are pretty clear improvements we can
make. I guess s/blacklist/blocklist/g is the clearest in most
cases I can think of, but there'll for sure be some cases
that are tricky. I think that's ok if the guidance is well
given.

> I'm against blind
> word substitution and I'm against banning of certain words. 

I'm also against "banning." That's based on my background
when as a youth I grew up in an environment where censorship,
more of discussion topics than specific words, was common.
So I'd hate to see us end up with a blocklist of bad strings.
But I don't think that's where this is headed.

Cheers,
S.

> And I think it
> is quite galling that affluent, credentialed, white people are at the
> forefront of this effort to define how groups of people who are not white,
> affluent, and credentialed behave when they read common terms of art.
> That's patronizing and it's offensive. So I'm against patronizing and
> offensive behavior, even if it's done with the best of intentions, but
> not necessarily against cleaning up our documents.
> 
>    regards,
> 
>    Dan.
> 
>> Ta,
>> S.
>>
>> [1] https://www.ieee802.org/1/files/public/docs2021/dr-PAR-0221-v01.pdf
>>
>> On 12/02/2021 00:25, Dan Harkins wrote:
>>>
>>>
>>> On 2/11/21 1:56 PM, Eric Rescorla wrote:
>>>>
>>>> On Thu, Feb 11, 2021 at 12:39 PM Sean Turner <[e-mail] 
>>>> <mailto:[e-mail]>> wrote:
>>>>
>>>>     Hi!,
>>>>
>>>>     Here is some proposed charter text to address the
>>>>     terminology-related WG.
>>>>
>>>>     Cheers,
>>>>     spt
>>>>
>>>>
>>>> This looks like a great start. A few small comments below.
>>>>
>>>>
>>>>     Effective Terminology in IETF Documents (TERM)
>>>>     ----
>>>>
>>>>     The mission of the IETF as specified in BCP 95 is to produce high
>>>>     quality, relevant technical documents that influence the way
>>>>     people design, use, and manage the Internet. As RFC 7322 explains,
>>>>     "The ultimate goal of the RFC publication process is to produce
>>>>     documents that are readable, clear, consistent, and reasonably
>>>>     uniform." RFCs and Internet-drafts are most effective when they
>>>>     use terminology that is clear, precise, and widely accessible to
>>>>     readers from varying backgrounds and cultures.
>>>>
>>>>     In the years leading up to the chartering of this working group,
>>>>     there has been discussion in the IETF, in other standards
>>>>     organizations, and in the technology industry about the use of
>>>>     certain terms (such as “master/slave” and “blacklist/whitelist”)
>>>>     in technical documentation and whether those and other terms have
>>>>     effects on inclusivity. While opinions vary among IETF
>>>>     participants about this topic, there is general agreement that the
>>>>     IETF community would benefit from informational recommendations
>>>>     about using effective and inclusive terminology in IETF documents.
>>>>     The TERM working group is therefore chartered to produce an
>>>>     Informational RFC containing recommendations on terminology to use
>>>>     in technical work produced by the IETF.
>>>>
>>>>
>>>> I think it might be helpful to scope out a little more what this RFC 
>>>> might contain. Perhaps:
>>>>
>>>> These recommendations will consist of (1) general principles for 
>>>> judging when language is inclusive or exclusive (2) a list of 
>>>> specific terms to avoid and recommendations for alternatives.
>>>
>>>    I agree with (1), in fact I would like to see some principles for 
>>> what defines "inclusive"
>>> and "exclusive". Right now it seems like how one defines pornography, 
>>> i.e. "I know it when
>>> I see it". The problem with that is that we end up with some 
>>> self-appointed New Moral Majority
>>> defining for everyone what "exclusive" or "inclusive" is, and I'm 
>>> sorry but hell no. I'd
>>> rather add some new fangled version of the Parental Advisory Notice 
>>> that the previous group
>>> of morality busybodies put on albums back in the 80s and 90s into the 
>>> boilerplate of RFCs
>>> and I-Ds.
>>>
>>>    As far as (2) is concerned, you only call out for a list of terms 
>>> to avoid and their
>>> replacement terms, which seems to play to the conspiracy that this 
>>> whole thing is about
>>> policing speech-- "you can't say that." Is "inclusive" merely the 
>>> alternative to the bad
>>> word that has been defined as "exclusive" or are there some words 
>>> that would make RFCs be
>>> more clear, precise, and widely accessible that don't have a naughty 
>>> synonym?
>>>
>>>    regards,
>>>
>>>    Dan.
>>>
>>>
>>
> 
>