Subject: [Terminology] WG Review: Effective Terminology in IETF Documents (term)

From: Lars Eggert <[email-masked]>
Date: Fri, 23 Apr 2021 17:43:16 +0300

Hi,

the latest version of the charter for TERM just went out for IETF-wide review. This is the second such review cycle, which I deemed necessary due to the number of changes to the charter text the first review resulted in.

Please send constructive comments on the charter for the proposed WG to [email-masked] <mailto:[email-masked]>, or privately to the IESG or even only to me as the responsible AD.

To make sure that your feedback is taken into account on this latest version of the charter text, I encourage you to send comments even if you commented during the last IETF review cycle, or when the charter was earlier discussed in GENDISPATCH.

Thanks,
Lars

> 
> A new IETF WG has been proposed in the General Area. The IESG has not made
> any determination yet. The following draft charter was submitted, and is
> provided for informational purposes only. Please send your comments to the
> IESG mailing list ([email-masked]) by 2021-05-03.
> 
> Effective Terminology in IETF Documents (term)
> -----------------------------------------------------------------------
> Current status: Proposed WG
> 
> Chairs:
>  TBD
> 
> Assigned Area Director:
>  Lars Eggert <[email-masked]>
> 
> General Area Directors:
>  Lars Eggert <[email-masked]>
> 
> Mailing list:
>  Address: [email-masked]
>  To subscribe: https://www.ietf.org/mailman/listinfo/terminology
>  Archive: https://mailarchive.ietf.org/arch/browse/terminology/
> 
> Group page: https://datatracker.ietf.org/group/term/
> 
> Charter: https://datatracker.ietf.org/doc/charter-ietf-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. Contributions to the IETF, including Internet-Drafts and
> RFCs, are most understandable and effective when they use terminology that is
> clear, precise, and widely accessible to readers from varying backgrounds and
> cultures. This maximizes the benefits the IETF derives from its central
> principles, such as its open process and volunteer core.
> 
> 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
> broader technology industry about the use of certain terms of art in
> technical writing and whether those and other terms have an exclusionary
> effect. While opinions vary among IETF participants about this topic, there
> is widespread agreement that the IETF community would benefit from advice
> about using effective terminology that would improve clarity and
> approachability.
> 
> The TERM working group is therefore chartered to produce an Informational RFC
> containing guidance to IETF participants on the use of effective terminology
> that also minimizes exclusionary effects. The RFC will express general
> principles for assessing when language is effective. The principles should be
> derived considering input from a broad set of IETF participants. The WG will
> identify and recommend external, independently updated resources containing
> examples of potentially problematic terms and potential alternatives to IETF
> participants for their consideration, to align its efforts with broader
> activities by the technology industry.
> 
> The TERM working group is a focused group aiming to produce a single
> deliverable. It is designed to complement other efforts at fostering
> inclusivity in the IETF and will liaise with appropriate external groups,
> such as other SDOs or industry initiatives, to coordinate.
> 
> The output of this WG will provide guidance to IETF participants and will not
> restrict the type or content of contributions that can be made to the IETF
> standards process. The output of this WG may inform a potential future
> activity by the RFC Editor to establish terminology guidance for the overall
> RFC series, but does not constrain any such future action.
> 
> Milestones:
> 
>  Jun 2021 - Adopt draft providing informational terminology recommendations
> 
>  Dec 2021 - Submit informational terminology recommendations to IESG

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 Apr 2021 17:01:33 +0200

On 2021-04-23, at 16:43, Lars Eggert <[email-masked]> wrote:
> 
>> The WG will
>> identify and recommend external, independently updated resources 

I’d add “a small set of” — this list is not intended to be exhaustive, but useful for authors (and the kitchen sink isn’t).

Grüße, Carsten

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Apr 2021 16:03:05 +0100

Hiya,

In general I support this.

I think it's a mistake to craft or point at a curated
list of bad terms as I've said before but I seem to be
in the rough on that, which is ok.

One related nit though:

> activities by the technology industry.

The "will" there seems wrong. Even if the WG does
identity a perfect external resource for this, that
resource could disappear or become lots less perfect
over time.

Maybe s/will identify and recommend/will consider and
potentially recommend/ or something like that?

Cheers,
S.

---

From: Keith Moore <[email-masked]>
Date: Fri, 23 Apr 2021 11:14:38 -0400

I continue to believe that using a WG to address this problem would be 
unwise, as WGs are structurally ill-suited for this kind of problem.   
It's an important problem, but I recommend that IESG find another 
mechanism to address this issue: one that meets for a short time, 
deliberately solicits wide input (perhaps even inviting participants 
from other standards bodies) and is less confrontational or promotes 
quicker resolution of conflicts than is typical for mailing list 
discussions.   An IAB workshop (if IAB is willing) or a workshop with a 
similar style even if someone other than IAB hosts it, seems like a 
better choice.   (Granted, it's probably helped that IAB workshops have 
in the past, to my knowledge, always been face-to-face meetings, which 
might not be feasible in the near term.)

If IESG decides to go ahead with this, I recommend (a) taking all words 
about "exclusionary" out of the charter; and (b) explicitly stating that 
the WG will be shut down if it doesn't produce a draft by X date and 
finish WGLC by Y date.   (I recommend X = July 31 and Y = Oct 31).

As I said in earlier comments, it is imperative to choose chairs for 
this WG who are completely neutral about controversial topics (such as 
social theories), and who will discourage discussion of any topic not 
strictly consistent with "will use of this word improve or degrade the 
clarity or readability of IETF documents?"   (or something close to that)

The obvious lack of neutrality by gendispatch chairs has done a lot to 
undermine the credibility of that group, and this proto-WG is already 
tainted by that.

Keith

On 4/23/21 10:43 AM, Lars Eggert wrote:
> Hi,
>
> the latest version of the charter for TERM just went out for IETF-wide 
> review. This is the second such review cycle, which I deemed necessary 
> due to the number of changes to the charter text the first review 
> resulted in.
>
> Please send constructive comments on the charter for the proposed WG 
> to [email-masked] <mailto:[email-masked]>, or privately to 
> the IESG or even only to me as the responsible AD.
>
> To make sure that your feedback is taken into account on this latest 
> version of the charter text, I encourage you to send comments even if 
> you commented during the last IETF review cycle, or when the charter 
> was earlier discussed in GENDISPATCH.
>
> Thanks,
> Lars
>
>>
>> IESG mailing list ([email-masked] <mailto:[email-masked]>) by 2021-05-03.
>>
>>  Lars Eggert <[email-masked] <mailto:[email-masked]>>
>>
>> General Area Directors:
>>  Lars Eggert <[email-masked] <mailto:[email-masked]>>
>>
>> Mailing list:
>>  Address: [email-masked] <mailto:[email-masked]>
>> <https://www.ietf.org/mailman/listinfo/terminology>
>> <https://mailarchive.ietf.org/arch/browse/terminology/>
>>
>> <https://datatracker.ietf.org/group/term/>
>>
>> <https://datatracker.ietf.org/doc/charter-ietf-term/>
>>
>> containing

---

From: "Maisonneuve, Julien (Nokia - FR/Paris-Saclay)" <[email-masked]>
Date: Fri, 23 Apr 2021 15:31:28 +0000

Hello,
This charter seems to be based on the consensus that something should be done to redress the language in IETF specs. This was not my understanding of the situation. I have seen a vocal group in favour of doing so, but nothing that looks like broad consensus, and a lot of doubters, along with people wary of getting drawn into what is a largely US-centric debate.
Is there a step to check that this consensus is achieved in IETF ?
Because if the consensus is checked only about the list of terms requiring censorship, I think we missed something.
Regards,
Julien (not representing the view of my employer).

From: ietf <[email-masked]> On Behalf Of Lars Eggert
Sent: Friday, April 23, 2021 4:43 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: WG Review: Effective Terminology in IETF Documents (term)

Hi,

Please send constructive comments on the charter for the proposed WG to [email-masked]<mailto:[email-masked]>, or privately to the IESG or even only to me as the responsible AD.

Thanks,
Lars

A new IETF WG has been proposed in the General Area. The IESG has not made
any determination yet. The following draft charter was submitted, and is
provided for informational purposes only. Please send your comments to the
IESG mailing list ([email-masked]<mailto:[email-masked]>) by 2021-05-03.

Chairs:
 TBD

Assigned Area Director:
 Lars Eggert <[email-masked]<mailto:[email-masked]>>

General Area Directors:
 Lars Eggert <[email-masked]<mailto:[email-masked]>>

Mailing list:
 Address: [email-masked]<mailto:[email-masked]>
 To subscribe: https://www.ietf.org/mailman/listinfo/terminology
 Archive: https://mailarchive.ietf.org/arch/browse/terminology/

Milestones:

---

From: Andrew Campling <[email-masked]>
Date: Fri, 23 Apr 2021 15:32:02 +0000

On 2021-04-23, at 15:43, Lars Eggert <[email-masked]<mailto:[email-masked]>> wrote:

>> Contributions to the IETF, including Internet-Drafts and

>> cultures.

I'd add ", including those for whom English is not their first language." I know that the language element is arguably implied by the existing text but I believe that it should be made explicit as some of the previous list contributions have included input from those of both different cultures and languages, however these inputs often appear to have been overlooked.  The WG will not succeed if it focuses solely on what are largely US-centric political sensitivities (important though these may be to their proponents).

Andrew

From: Lars Eggert <[email-masked]>
Sent: 23 April 2021 15:43
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Gendispatch] WG Review: Effective Terminology in IETF Documents (term)

Hi,

Thanks,
Lars

Chairs:
 TBD

Assigned Area Director:

General Area Directors:

Mailing list:

Milestones:

---

From: "Jim Fenton" <[email-masked]>
Date: Fri, 23 Apr 2021 09:17:09 -0700

> in the rough on that, which is ok.

I’m not sure you are “in the rough” on that. I would much rather 
see the WG craft a set of principles with respect to document 
inclusiveness than to curate a blocklist of bad terms or reference 
someone else’s list. It would be fine to include some non-normative 
examples to illustrate what is being talked about, however. IMO it’s 
possible to use certain of the frequently-discussed words without being 
non-inclusive, and it’s definitely possible to be non-inclusive 
without using any of those words.

Before someone points out that this is only to be an Informational RFC, 
a lot of people don’t see the “informational” label. I can point 
to informational RFCs that government agencies have mandated deployment 
of, and at least one agency is already pointing to 
draft-knodel-terminology-01 as “IETF”, illustrating how easy it is 
to have these things over-interpreted.

-Jim

---

From: Eliot Lear <[email-masked]>
Date: Fri, 23 Apr 2021 18:29:47 +0200

Lars,

I’m very sorry to bring you back to a particular point.

> On 23 Apr 2021, at 16:43, Lars Eggert <[email-masked]> wrote:
> 
>>  The RFC will express general
>> derived considering input from a broad set of IETF participants.

That’s not really something our community is expert in doing, and we should not pretend that we are.  We are engineers; not linguistic anthropologists, ethicists, philosophers, or neurolinguists.  The best I can come up with to address this is:

> The RFC will leverage generally acceptable principles for assessing when language is effective.

But I don’t know if they exist.

Personally I thought Bron’s draft hit the right tone on this, and any charter text that is similarly scoped would be ok.

Eliot

---

From: Andrew Campling <[email-masked]>
Date: Fri, 23 Apr 2021 16:37:55 +0000

> Personally I thought Bron’s draft hit the right tone on this, and any charter text that is similarly scoped would be ok.

+1

It’s certainly my recollection that the consensus of the Gendispatch discussion at the time of IETF109 was that Bron’s draft was the right starting point, not least because of its positive tone.  No doubt others will comment if they feel my recollection is incorrect.

Andrew

---

From: Lloyd W <[email-masked]>
Date: Sat, 24 Apr 2021 18:31:21 +1000

Stephen

how can you support this if you think a list of bad terms is a mistake, which means that you don't support this?

Can you actually clearly articulate your position?

thanks,

Lloyd Wood
[email-masked]

I support the war in general, just not any of the actions that the war requires.

> On 24 Apr 2021, at 01:03, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 24 Apr 2021 21:25:34 +0100

On 24/04/2021 09:31, Lloyd W wrote:
> Stephen
> 
> how can you support this if you think a list of bad terms is a
> mistake, which means that you don't support this?

No that's not correct. The list is only one aspect of the
overall charter.

I'm fine with a WG crafting an informational RFC that gives
us better guidance as to how to write better drafts, and am
ok that that includes a few examples of terms that are now
considered less good.

I think a curated list of bad terms is a mistake because it
threatens to prolong and occasionally re-ignite controversies
around terminology. Secondly, no matter what opinion one
holds on any specific term, the risk exists that the list's
then curators have the opposite opinion at some future date.
So, I think it's a mistake to consider such a list from any
starting position.

Cheers,
S.

> 
> Can you actually clearly articulate your position? >
> thanks,
> 
> Lloyd Wood [email-masked]
> 
>> I think it's a mistake to craft or point at a curated list of bad
>> terms as I've said before but I seem to be in the rough on that,
>> which is ok.
>

---

From: [email-masked]
Date: Sat, 24 Apr 2021 19:48:00 -0400

(I am a new subscriber, so I apologize in advance if I break any 
conventions.  Thanks.)

A couple of points concerning a list, I would think that any list of 
good words would have to say the bad words with which the good 
correlate.  Otherwise one is in the position of a person trying to guess 
from contextuual clues what a redacted word might be.  Which is common 
in living languages, but is difficult without some amount of shared 
context.  But including the bad words leads to the problem of 
auto-filtering eliminating the list; which leads to the need for a 
special status by which bad words can be identified as being merely 
written about.  (This is the usual problem of confusing meaningful use 
of a word versus merely talking about the word as a word, ie mentioning 
it.  There is a lot of philosophy and logic about this.  The usual 
solution is to distinguish mention cases by identifying with some or 
other quote mark--including finger quotes--any occurrence of a word 
being mentioned.)

As for having a list, I think any occurrence can be taken to be a list, 
eg a singleton word-pair can be taken to be a one-member list, normal in 
computing.  If the example is in regular prose writing, there is more 
context than there is for the usual idea of the efficiency of the list 
form.  A hybrid could be a list entry being a word-pair plus a brief 
example usage.

As for controversy, these are controversial times.  If IETF wants some 
internal advice people--internal or exteral--can refer to, why not try 
to do one's part to help.

Cheers.
Tom

> So, I think it's a mistake to consider such a list from any
  . . .

---

From: Lloyd W <[email-masked]>
Date: Sun, 25 Apr 2021 10:07:20 +1000

Stephen,

an informational RFC including 'a few examples of terms' in itself constitutes a curated list, set in stone. Who decides and crafts that initial list? Slippery slope, that. The controversies start well before that RFC is done.

And, with that in mind, that's why I wrote

https://datatracker.ietf.org/doc/draft-wood-term-modest-proposal/
https://tools.ietf.org/html/draft-wood-term-modest-proposal-annotations-00

just to call out some problems that I could see with the list idea (and include better terminology than 'less good'j.

And after those drafts were published, 00-04 of the terminology charter was produced, which handily removed any mention of two terms for the list -- because a document without any list of terms is so much more palatable than a document with a list. (and two items IS a list.)

yes, the curators of this hypothetical list (or lists) may change their minds at a future date. But the trend is to more authoritarianism, not less. Terms that are added to the list clearly should always have been on the list and will always be on the list, and who are we, or they, to question that?

I think we're long past the point of 'just be sensible and apply best engineering judgement'.

Lloyd Wood
[email-masked]

for my next inspired-by-the-modern-classics draft I will be drawing upon Joyce and Ulysses. Seems utterly pointless. But I do have until Bloomsday.

> On 25 Apr 2021, at 06:25, Stephen Farrell <[email-masked]> wrote:
> 
> 
> <OpenPGP_0x5AB2FAF17B172BEA.asc>
> -- 
> Terminology mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/terminology

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 25 Apr 2021 02:01:48 +0100

On 25/04/2021 01:07, Lloyd W wrote:
> Stephen,
> 
> an informational RFC including 'a few examples of terms' in itself
> constitutes a curated list, set in stone.

I don't agree. Set-in-stone != curated. E.g., I have
no problem if we emit an RFC that recommends that
blocklist is currently considered better than blacklist
in almost all cases.

> Who decides and crafts that
> initial list? 

The WG, followed by IETF LC. All normal stuff. Hopefully
the draft/RFC will have additional positive guidance and
not just a couple of examples of what to not do.

But my comment on the charter was more to the effect
that considering that an "initial" list would be a mistake,
for (at least) the reasons stated in my mail in response
to yours.

...snip...

> yes, the curators of this hypothetical list (or lists) may change
> their minds at a future date. But the trend is to more
> authoritarianism, not less. 

Who knows what'll happen in future? My imperfect guess
is that we'll mostly lose interest once the fuss dies
down TBH;-)

Personally, I'll oppose attempts to create any curated
list of prohibited terms, but I'm fine with doing that
later, if/as needed. (I'm sanguine about having to oppose
that even if the charter text says it "will" be done,
as I'm fairly sure the proponents of that will see that
it's a bad plan later if not sooner - another level of
indirection may be good CompSci practice in general, but
likely isn't the right plan here:-)

Cheers,
S.

---

From: Lloyd W <[email-masked]>
Date: Sun, 25 Apr 2021 12:42:36 +1000

Stephen,

"RFC 10984 on inclusive terminology obsoletes RFC 9184 on inclusionary terminology. This new product of the TERMINATOR (formerly TERM) workgroup specifically adds the following terms, which are now discouraged from use:

exclusive (and variants)
fnord (not fjord! fjord is fine! [At this time.])
huxleyan (and variants)
I'll be blocked
orwellian (and variants)
poison attack
timestamp crank..." etc.

curation for RFCs is not strictly set in stone, as you say. But with RFCs, the published list curation and modification process is rather more drawn out, carefully thought out, and tedious, which is arguably a good thing, at least until you're in the middle of arguing the next round of changes to be published. It's rather like trying to engrave one's own headstone. with a spoon.

If you start with any list, anyhow, that list will only grow.

can someone please tell the RFC Ed to reserve RFC 9184 for TERM...

Lloyd Wood
[email-masked]

> On 25 Apr 2021, at 11:02, Stephen Farrell <[email-masked]> wrote:
>

---

From: Pete Resnick <[email-masked]>
Date: Sat, 24 Apr 2021 22:39:23 -0500

[Chair hat]

I'd really appreciate if people would remove gendispatch from the Cc 
line (or at least move it to a Bcc) unless you really think gendispatch 
needs to be part of this discussion. The TERM charter is not a 
gendispatch topic.

Cheers,

pr

-- 
Pete Resnick https://www.episteme.net/
All connections to the world are tenuous at best

---

From: Eliot Lear <[email-masked]>
Date: Sun, 25 Apr 2021 11:14:28 +0200

[I am reducing this from gendispatch in accordance with the IESG’s request.]

> On 25 Apr 2021, at 01:48, [email-masked] wrote:
> 
> (I am a new subscriber, so I apologize in advance if I break any conventions.  Thanks.)

Welcome to the party, Tom.

> 
> A couple of points concerning a list, I would think that any list of good words would have to say the bad words with which the good correlate.  Otherwise one is in the position of a person trying to guess from contextuual clues what a redacted word might be.  Which is common in living languages, but is difficult without some amount of shared context.  But including the bad words leads to the problem of auto-filtering eliminating the list; which leads to the need for a special status by which bad words can be identified as being merely written about.  (This is the usual problem of confusing meaningful use of a word versus merely talking about the word as a word, ie mentioning it.  There is a lot of philosophy and logic about this.  The usual solution is to distinguish mention cases by identifying with some or other quote mark--including finger quotes--any occurrence of a word being mentioned.)

> 
> As for having a list, I think any occurrence can be taken to be a list, eg a singleton word-pair can be taken to be a one-member list, normal in computing.  If the example is in regular prose writing, there is more context than there is for the usual idea of the efficiency of the list form.  A hybrid could be a list entry being a word-pair plus a brief example usage.

Mostly what you are raising above is about auto-substitution.  I have seen some tools that do just that sort of thing, and in fact, the place where I really want the help as an individual is in the same logic that I can find with my spell checker.  [Such an addition would be particularly useful for pronouns, especially if I have indications in my address book of what a person’s preferred pronouns are.]

I think you’re also coming at this from the right angle, in that, given a list, tooling would at least flag the bad words, just as our model checkers flag bad yang, and our Internet Drafts nits checker flags common errors.  However, as with those other tools, I suggest that the “fixing” part should be left to the authors and WGs.

> 
> As for controversy, these are controversial times.  If IETF wants some internal advice people--internal or external--can refer to, why not try to do one's part to help.

Within the limits of one’s expertise, I would agree.  As we are not subject matter experts at establishing principles for this sort of thing– our community is comprised on the whole engineers, “external” seems to me to be the wise choice, so that we can benefit from those who are experts.  If by some strange stretch we were to attract a reasonable pool of such experts, I would of course feel somewhat differently.  Even then, we would have to guard against we engineers interjecting our layman views.

Eliot

---

From: Mallory Knodel <[email-masked]>
Date: Mon, 26 Apr 2021 09:13:54 -0400

Hi Eliot,

On 4/23/21 12:29 PM, Eliot Lear wrote:
>> On 23 Apr 2021, at 16:43, Lars Eggert <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> � The RFC will express general
>>> derived considering input from a broad set of IETF participants.�
>
> That’s not really something our community is expert in doing, and we 
> should not pretend that we are.  We are engineers; not linguistic 
> anthropologists, ethicists, philosophers, or neurolinguists.  The 
> best I can come up with to address this is:
>
First, there are experts here. There are many of us in the IETF who in 
big and small ways have dedicated our careers to making tech more inclusive.

Second, we should ask every professional environment, from automobile 
plants to kindergarten classrooms, to be intentionally inclusive. The 
"not experts" argument is a dodge.

If we rely on the Inclusive Naming Initiative, for example, as an 
external resource, it is comprised of people who work for some of the 
very same companies that engage in the IETF. Let's lay this argument to 
rest please,

-Mallory

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 Apr 2021 17:24:38 +0200

Mallory

> Second, we should ask every professional environment, from automobile plants to kindergarten classrooms, to be intentionally inclusive. The "not experts" argument is a dodge.

You mischaracterized my position.  What I am saying is that the WG shouldn’t try to decide for itself what EXclusive language is, for the very same reason that a cancer patient wouldn’t select an engineer as an oncologist.  The INI is a perfect example the WG should leverage, as it is chartered to serve as a locus of expertise around inclusive language.  The IETF is not.

Eliot

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 27 Apr 2021 17:19:44 +0200

Dear IESG,

Thank you for this opportunity to comment on the draft charter. Please allow me to make a couple of points on the newly proposed charter in-line below.

On 23-04-2021 16:43, Lars Eggert wrote:
>>  To subscribe: https://www.ietf.org/mailman/listinfo/terminology <https://www.ietf.org/mailman/listinfo/terminology>
>>  Archive: https://mailarchive.ietf.org/arch/browse/terminology/ <https://mailarchive.ietf.org/arch/browse/terminology/>
>>
>> Group page: https://datatracker.ietf.org/group/term/ <https://datatracker.ietf.org/group/term/>
>>
>> Charter: https://datatracker.ietf.org/doc/charter-ietf-term/ <https://datatracker.ietf.org/doc/charter-ietf-term/>
>>
>> effect. 

If we are precise about this, it is probably better to describe the actual situation, namely that the majority of the tech industry and other standards bodies have reached consensus on the topic, and the IETF is still making up its mind. It would good to (re-)add an example here. 

While opinions vary among IETF participants about this topic, there
>> about using effective terminology that would improve clarity and

s/approachability/participation

>> that also minimizes exclusionary effects. 

suggestion

s/effective terminology that also minimizes exclusionary effects/effective and inclusive terminology.

>> principles for assessing when language is effective. 

suggestion: and inclusive

>> The principles should be

suggestion: and/or experts in the field

>> activities by the technology industry.

suggestion: and rely on academic research in this field. 

>> deliverable. 

Suggestion: add 'minimally'

>> It is designed to complement other efforts at fostering
>> inclusivity 

suggestion: and diversity

>> in the IETF and will liaise with appropriate external groups,
>> standards process. 
>> The output of this WG may inform a potential future

I would suggest re-adding examples of exclusionary language to the charter, because it makes the work of the WG, and the motivation to do the work, much more concrete. At times the charter now reads like it is a WG to address the use (non-)usage of the Oxford comma. 

But in the end I simply hope we can get this work done and out the door because we all seem to agree there is much more work to be done.

All the best,

Niels

-- 
Niels ten Oever, PhD
Postdoctoral Researcher - Media Studies Department - University of Amsterdam
Research Fellow - Centre for Internet and Human Rights - European University Viadrina
Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas

https://nielstenoever.net - [email-masked] - @nielstenoever - +31629051853
PGP: 2458 0B70 5C4A FD8A 9488 643A 0ED8 3F3A 468A C8B3

Read my latest article on Internet infrastructure governance in New Media & Society here: https://journals.sagepub.com/doi/full/10.1177/1461444820929320

---

From: Mallory Knodel <[email-masked]>
Date: Tue, 27 Apr 2021 11:53:56 -0400

+1 Niels,

More:

> suggestion: and diversity

The industry phrase is "diversity, equity and inclusion" and I think 
worth going with this standard notation.

-Mallory

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 27 Apr 2021 15:57:10 +0000

> The industry phrase is "diversity, equity and inclusion" and I think worth going with this standard notation.

+1

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 27 Apr 2021 18:08:30 +0200

>> The industry phrase is "diversity, equity and inclusion" and I think worth going with this standard notation.

+1 am all about standards :))
-- 
Niels ten Oever, PhD
Postdoctoral Researcher - Media Studies Department - University of Amsterdam
Research Fellow - Centre for Internet and Human Rights - European University Viadrina
Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 28 Apr 2021 22:29:48 -0400

> On Apr 26, 2021, at 9:13 AM, Mallory Knodel <[email-masked]> wrote:
> 
> First, there are experts here. There are many of us in the IETF who in big
> and small ways have dedicated our careers to making tech more inclusive.

What it takes to make "tech" more inclusive is a change in the broader
culture that entices a large segment of the population to consider
a technical career.  My parents were born into a generation in the
USSR for which the best opportunities of a rewarding career were in
engineering (and engineers typically earned better or equal pay to
doctors or other professions).  The general culture at the time was
also more egalitarian (also totalitarian, but the two are not mutually
exclusive).

Thus, both my parents are engineers, and this was by no means uncommon
for their generation.

Career choices are driven by many social factors related to how those
careers are generally perceived.  Words like "nerd" and "geek" were
simply not part of the culture there and then, and families needed
two working parents to just get by.  A homemaker parent was not an
option many could afford.

Fortunately for many of us there are today many more choices, but less
fortunately, the social status of engineers in e.g. the USA is not
nearly as high here and now as it was there and then.

So there is little social pressure for the most successful students
to choose engineering over law, medicine, finance, ... and so, for
better or worse, a more self-selected pool of candidates chooses "tech"
careers.

Education opportunities further limit the pool of candidates, by not
providing quality instruction in mathematics and the sciences to
under-privileged students.

This reality and not the terminology of technical documents is what
shapes the demographics of the IETF and other technical disciplines.

If you want to make "tech" more inclusive, make it more attractive
than other options, but in a society where less is dictated from
the top, that is not always easy or even possible.

Instead, we witness futile efforts largely akin to rearranging the chairs
on the deck of the Titanic.  The terminology battle will only serve to
discourage those turned off by its political correctness, without
materially addressing the demographic imbalance.  If the goal is to make
sure that only those comfortable with political correctness feel welcome
to participate, then this effort will succeed in furthering that goal.
The evidence that it will achieve anything else is sorely lacking.

> "not experts" argument is a dodge.

My view is that is the whole question of "experts" is misplaced.  Sure
we can find experts in terminology nuances, but my take is that the
expertise in question is largely irrelevant to the stated goals of
a diversified more inclusive IETF.  Indeed every indication I see is
that the net effect will be largely negative, discouraging many without
materially helping to bring in new perspectives.

> external resource, it is comprised of people who work for some of
> the very same companies that engage in the IETF. Let's lay this
> argument to rest please.

That presumes that the question of whether this whole enterprise
is folly is settled and out of scope.

-- 
	Viktor.

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Apr 2021 15:37:30 -0400

> s/effective terminology that also minimizes exclusionary effects/effective and inclusive terminology.

Let's please completely omit any notion of both "exclusionary effects" 
and "inclusive terminology" from the charter.   Both are dubious, poorly 
defined, and poorly supported notions; and both are needlessly divisive.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Apr 2021 15:47:47 -0400

On 4/27/21 11:19 AM, Niels ten Oever wrote:

> it is probably better to describe the actual situation, namely that the majority of the tech industry and other standards bodies have reached consensus on the topic, and the IETF is still making up its mind.

IMO this is a bit unfair for multiple reasons.

But it's certainly fair to say that IETF is slower than we'd like to be 
at developing technical standards, and even slower at developing 
standards for itself - because we never developed an effective process 
for the latter.

Keith

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 29 Apr 2021 19:55:27 +0000

*   Let's please completely omit any notion of both "exclusionary effects" and "inclusive terminology" from the charter.   Both are dubious, poorly defined, and poorly supported notions; and both are needlessly divisive.

Good grief, please no.

The point of this WG is to do exactly what you would have struck from the charter. I understand that some people are opposed to do doing this, and their reasons are varied. But please understand that some believe equally strongly that this is important to do. Making the charter something that is so unobjectionable and anodyne goes against the specificity that we encourage in every other charter.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 29 Apr 2021 19:58:38 +0000

>    IMO this is a bit unfair for multiple reasons.

I would like to know why you think this is an unfair characterization.  Heck, even NIST has come out with a specification on this topic, https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8366.pdf , "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards"

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Apr 2021 18:39:17 -0400

Sent from my iPhone

> On Apr 29, 2021, at 3:55 PM, Salz, Rich <[email-masked]> wrote:
> 
> The point of this WG is to do exactly what you would have struck from the charter.

Yet another reason why the group should not be chartered.

Either we find common cause or getting consensus is hopeless.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Apr 2021 20:58:43 -0400

On 4/29/21 3:58 PM, Salz, Rich wrote:

> I would like to know why you think this is an unfair characterization.  Heck, even NIST has come out with a specification on this topic,https://nvlpubs.nist.gov/nistpubs/ir/2021/NIST.IR.8366.pdf  , "Guidance for NIST Staff on Using Inclusive Language in Documentary Standards"

I think it's making an argument not on its merits, but by appeal to 
fashion or herd mentality.    It also presumes that the framing of the 
topic is beyond question, when as far as I can tell it's extremely 
biased in such a way as to presume a particular answer.    There's more 
but I think I'll leave it at that.

Keith

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 30 Apr 2021 11:41:09 +0200

On 29-04-2021 21:47, Keith Moore wrote:
> But it's certainly fair to say that IETF is slower than we'd like to be at developing technical standards, and even slower at developing standards for itself - because we never developed an effective process for the latter.
> 

The development of 3GPP and IEEE standards and procedures is generally slower than in the IETF. There is some quite good quantitative analysis on this. 

So I do think the characterization I initially provided is factually correct and fair, both absolutely and relatively. 

Best,

Niels

-- 
Niels ten Oever, PhD
Postdoctoral Researcher - Media Studies Department - University of Amsterdam
Research Fellow - Centre for Internet and Human Rights - European University Viadrina
Associated Scholar - Centro de Tecnologia e Sociedade - Fundação Getúlio Vargas
Affiliated Factulty - Digital Democracy Insitute - Simon Fraser University

---

From: Keith Moore <[email-masked]>
Date: Fri, 30 Apr 2021 06:51:07 -0400

> The development of 3GPP and IEEE standards and procedures is generally slower than in the IETF. There is some quite good quantitative analysis on this.

I didn't say we were the slowest, just slower than we'd like.

Keith

---

From: S Moonesamy <[email-masked]>
Date: Fri, 30 Apr 2021 04:22:38 -0700

Hi Keith, Niels,
At 12:47 PM 29-04-2021, Keith Moore wrote:
>>it is probably better to describe the actual situation, namely that 
>>the majority of the tech industry and other standards bodies have 
>>reached consensus on the topic, and the IETF is still making up its mind.
>
>But it's certainly fair to say that IETF is slower than we'd like to 
>be at developing technical standards, and even slower at developing 
>standards for itself - because we never developed an effective 
>process for the latter.

It still comes down to the IETF is still up its mind.

A consensus-based approach is not suitable for quick decision-making 
as such as approach is meant to be slow.  The current proposed work 
does not even fit in the existing procedure given that it is an 
editorial matter.

Will an IETF decision be relevant after the publication of the 
guidance from NIST Staff?

Regards,
S. Moonesamy

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 30 Apr 2021 14:17:55 +0000

>    Either we find common cause or getting consensus is hopeless.

rough consensus not complete agreement.

---

From: Keith Moore <[email-masked]>
Date: Fri, 30 Apr 2021 10:48:33 -0400

> rough consensus not complete agreement.

The way I see it, if you can define a problem in a way that pretty much 
everyone will agree on the problem statement, you have a much easier 
time getting some kind of consensus, than if you try to define the 
problem in a way that is controversial.  The solutions in the two cases 
might be the same or very similar, except that you might never reach a 
solution in the latter case and you might create a lot of unnecessary 
bitterness in the process.

Keith

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 30 Apr 2021 15:12:32 +0000

everyone will agree on the problem statement, you have a much easier 
    time getting some kind of consensus

I am sure we have chartered working groups that did not have unanimity.

HOWEVER, since we seem to be rapidly converging on referencing the NIST document, I'm just gonna shut up. :)