Effective Terminology in IETF Documents
charter-ietf-term-00-07

[Ballot comment]
I have my reservations about this method of addressing the issue.  However, since this is just approval for external review, I'm content to let this version go and see what comments the community has.

[Ballot comment]
I have my reservations about this method of addressing the issue.  However, since this is just approval for external review, I'm content to let this go and see what comments result.

[Ballot comment]
After reading much (by no means all) of the list traffic, and after reading all the Abstain positions others have written, I’m going with “yes” on this one. To me it seems like some of the sentiments expressed by the more skeptical amount to perfect being the enemy of good. Furthermore — and this is the deciding point for me — in the broader industry, the train has clearly left the station. We can lead, follow, or get out of the way, but doing nothing would be tantamount to standing on the tracks.

I do think the charter has improved significantly since earlier versions, although I also agree with Éric’s remark about “hollow marketing language” at the end of the first paragraph.

[Ballot comment]
I acknowledge the risks associated with this initiative (as outlined by other ADs) but I think that on the long run this will engender more benefits than problems.
Yet, I think something important is missing.
The output of the WG, if it goes all the way through the IETF Stream, will have IETF-wide consensus.
While it is impossible to anticipate on the actual terminology recommandations the WG will make, I believe the charter should take a position (or lead the WG to make a recommandation) on how to handle initiatives aiming at revising/updating/obsoleting IETF past publications with the purpose of changing terms they contain.

[Ballot comment]
[re-posting my ballot position, which fundamentally hasn't changed since the previous iteration, since it's not about the text itself]

While I also agree with my co-ADs that any effort to make the IETF more
inclusive is important (and I won't repeat everything Warren, Rob or Éric
already said about supporting inclusivity efforts in IETF and aligning with
other SDO's similar efforts) I don't think I can ballot anything else than
Abstain. If there was a Recuse button, I would ballot that instead, but as
there is not I am abstaining instead. There are mainly two reasons for this:

1. And most important - I have co-chaired gendispatch and shepherded the first
proposal on this topic through the recommendation to create a WG (based on
draft-gondwana-effective-terminology) [1], and although I have been as unbiased
as possible, it would feel strange for me to approve on the chartering of this
working group, while I also (together with my co-chair and AD at the time)
evaluated the community consensus that lead to effort on chartering the working
group.

2. Because I have followed the discussion on the topic very actively, if not
since the beginning at least since its arrival in gendispatch at IETF108, I am
concerned about the potential of this work to create divisiveness and hurt in
the community, and I am worried about the potential of the working group of
being destructive rather than constructive.

The conclusion is that I have a serious concern about this working group being
chartered, but as my concern is not actionable, and as I stand behind my
evaluation of consensus at the time of chairing gendispatch (after hearing the
community speak in 1 meeting, 2 interims [2], and countless emails [3]), I will
not block this effort. I however wanted to mark my opinion and make sure the
resp AD and the whole IESG pays particular attention to its evolution.

Additionally, as an actionable comment, I still think mentioning in the charter
that draft-gondwana-effective-terminology is the starting point of this work
might help.

Francesca

[1]
https://mailarchive.ietf.org/arch/msg/gendispatch/iHDh7KBVRvGB2EWKYYh11LjP95E/
[2] https://datatracker.ietf.org/doc/minutes-108-gendispatch/
      https://datatracker.ietf.org/doc/minutes-interim-2020-gendispatch-01-202009012000/
      https://datatracker.ietf.org/doc/minutes-interim-2020-gendispatch-03-202009071100/
[3] https://mailarchive.ietf.org/arch/browse/gendispatch/?q=terminology
(excerpt, I know there is more)

[Ballot comment]
[ Simply reapplying my previous ballot position]

I agree that we should not be using terms that are, or could be, offensive, hurtful or send discouraging signals. I also believe that the vast majority of people in the IETF who do use terms like this are doing it unthinkingly, and without malice. These two precepts lead to the “it would be good if we had a resource where we would learn about terms which may be offensive, and easy replacements for those terms”. So far, so good….

In addition, I’m very supportive of building an IETF where anyone, and everyone, feels comfortable and welcome participating. The question for me is not whether this should be done, but rather what is the most effective, inclusive, ground-up method that will have the most buy-in and be the easiest to build upon further.

I don’t think that a working group is the right way to accomplish this - I oscillated between Abstain and NoObj, and finally settled on NoObj because I want to be clear that I do take the problem itself seriously. People should *want* to treat each other well, and anything “official” created by the IETF (like a WG) seems, to me, like it doesn’t solve the root problems, and probably makes them worse.  I understand that this WG is “chartered to produce an Informational RFC containing recommendations on the use of inclusive terminology in the technical work produced by IETF participants.”, and that this is supposed to “complement other efforts at fostering inclusivity in the IETF”.  My concern is that this approach will simply further polarize the community, and will lead to more division and antagonism.  Telling someone they are bad and must change doesn’t generally work; it generally makes them feel like they are being judged, become defensive, and attempt to justify, if not perpetuate, those behaviors. Helping them understand why their actions may be considered harmful  seems much more useful and likely to result in a positive change.

Even if we were to magically remove all terms which might cause offense to someone, I don’t think that that fixes our inclusivity issues, and, based upon the fact that we clearly have some set of people who are trolling for a fight, I think it makes things worse.

I would much rather that we instead work on actually addressing the inclusivity problems and treat the malady and not just the symptoms. More focus/resources on newcomers, meetings in more countries, discounts for first time attendees (and better student support), plenaries on inclusivity (and understanding other cultures!), more focus on things like GAIA, etc all seem (to me!) useful.

There are already resources for people who want to improve - anything “official” like an IETF WG / RFC is (in my opinion) likely to just trigger the trolls and give them more of a platform. For potential newcomers to the IETF, I’d prefer the larger “most of us are actually nice people” context to be in the forefront, instead of a loud, unpleasant, minority. In summary, I’m all for helping people understand why some terms are hurtful/harmful - but I don’t think that the current way we are trying to accomplish this works…

I understand that I’m in the rough here. I understand that (and why) many want this chartered. I’m not trying to block progress, I just don’t think that this is is going to make things better…  but I will not stand in the way of those who do.

I *do* believe that the inclusivity problem is important, but I also think that the chartering of a WG/publication of an RFC  is likely to make the issue worse, not better. You cannot mandate that people be nice; attempting to do so *may* send the signal externally that we are trying to improve, but ultimately, I think, it makes the division in the community worse, and makes the IETF a less welcoming place. People need to be encouraged to be better, this effort, I fear, will be viewed as telling them what to do - and this leads to defensiveness and outrage...

[Ballot comment]
[No really changing my position as it is based not on the charter itself but more about forming a WG around this topic]

The diversity and inclusion issues are critical within the IETF community (and in IETF documents).  But I am very skeptical whether any informational RFC will change anything or have any useful impact, I am also concerned that this WG could become divisive among the IETF community... polarization has, alas, become common in the recent years in all fora.

Moreover, even if this potential WG publishes documents, let's not declare victory and let's not wash our hand of the real problem.

Beside D&I, it is also important on the editorial side to keep a common terminology with other SDO... so, there are editorial guidelines to be written, but, again unsure whether a WG is the best place.

Hence my 'ABSTAIN' position in the sense of 'I oppose the creation of a TERM WG but understand that others differ and am not going to stand in the way of the others'.

On the charter text itself (updated):

"This maximizes the benefits the IETF derives from its central principles, such as its open process and volunteer core." Still sounds really like a hollow marketing statement to me...

s/The output of this WG will provide guidance to IETF participants/The output of this WG, if published, will provide guidance to IETF participants/ ,i.e., a WGLC should not be enough.

Having said this, let's continue to look for a more diverse and inclusive IETF community, which is more important and goes beyond words.

Regards

-éric

[Ballot comment]
Several of my fellow ADs who are abstaining or DISCUSSing have captured my position nicely.  The larger problem(s) here probably need to be addressed in a scope different from what's being proposed here.  Thus, on reflection, I too am concerned that the output of this WG as proposed might make things worse rather than better, but I do not wish to stand in the way of progress of the consensus opinion.

I respectfully ABSTAIN.

[Ballot comment]
I agree that we should not be using terms that are, or could be, offensive, hurtful or send discouraging signals. I also believe that the vast majority of people in the IETF who do use terms like this are doing it unthinkingly, and without malice. These two precepts lead to the “it would be good if we had a resource where we would learn about terms which may be offensive, and easy replacements for those terms”. So far, so good….

In addition, I’m very supportive of building an IETF where anyone, and everyone, feels comfortable and welcome participating. The question for me is not whether this should be done, but rather what is the most effective, inclusive, ground-up method that will have the most buy-in and be the easiest to build upon further.

I don’t think that a working group is the right way to accomplish this - I oscillated between Abstain and NoObj, and finally settled on NoObj because I want to be clear that I do take the problem itself seriously. People should *want* to treat each other well, and anything “official” created by the IETF (like a WG) seems, to me, like it doesn’t solve the root problems, and probably makes them worse.  I understand that this WG is “chartered to produce an Informational RFC containing recommendations on the use of inclusive terminology in the technical work produced by IETF participants.”, and that this is supposed to “complement other efforts at fostering inclusivity in the IETF”.  My concern is that this approach will simply further polarize the community, and will lead to more division and antagonism.  Telling someone they are bad and must change doesn’t generally work; it generally makes them feel like they are being judged, become defensive, and attempt to justify, if not perpetuate, those behaviors. Helping them understand why their actions may be considered harmful  seems much more useful and likely to result in a positive change.

Even if we were to magically remove all terms which might cause offense to someone, I don’t think that that fixes our inclusivity issues, and, based upon the fact that we clearly have some set of people who are trolling for a fight, I think it makes things worse.

I would much rather that we instead work on actually addressing the inclusivity problems and treat the malady and not just the symptoms. More focus/resources on newcomers, meetings in more countries, discounts for first time attendees (and better student support), plenaries on inclusivity (and understanding other cultures!), more focus on things like GAIA, etc all seem (to me!) useful.

There are already resources for people who want to improve - anything “official” like an IETF WG / RFC is (in my opinion) likely to just trigger the trolls and give them more of a platform. For potential newcomers to the IETF, I’d prefer the larger “most of us are actually nice people” context to be in the forefront, instead of a loud, unpleasant, minority. In summary, I’m all for helping people understand why some terms are hurtful/harmful - but I don’t think that the current way we are trying to accomplish this works…

I understand that I’m in the rough here. I understand that (and why) many want this chartered. I’m not trying to block progress, I just don’t think that this is is going to make things better…  but I will not stand in the way of those who do.

[ Update: I had balloted NoObj, but I'm changing to Abstain after yet more thought. I *do* believe that the inclusivity problem is important, but I also think that the chartering of a WG/publication of an RFC  is likely to make the issue worse, not better. You cannot mandate that people be nice; attempting to do so *may* send the signal externally that we are trying to improve, but ultimately, I think, it makes the division in the community worse, and makes the IETF a less welcoming place. People need to be encouraged to be better, this effort, I fear, will be viewed as telling them what to do - and this leads to defensiveness and outrage... ]

[Ballot comment]
[Updating my ballot position from NO RECORD to ABSTAIN after more thinking]

The diversity and inclusion issues are critical within the IETF community (and in IETF documents).  But I am very skeptical whether any informational RFC will change anything or have any useful impact, I am also concerned that this WG could become divisive among the IETF community... polarization has, alas, become common in the recent years in all fora.

Beside D&I, it is also important on the editorial side to keep a common terminology with other SDO... so, there are editorial guidelines to be written, but, again unsure whether a WG is the best place.

Hence my 'ABSTAIN' position in the sense of 'I oppose the creation of a TERM WG but understand that others differ and am not going to stand in the way of the others'.

On the charter text itself (unchanged from my previous NO RECORD COMMENTS):

Thanks for addressing my previous comments ;-)

Nevertheless, I am puzzled by the replacement of "work produced by IETF" by "work produced by IETF participants" because "IETF" includes the processes, BCP, RFC Editor, etc. while "IETF participants" does not (at least for a non English speaker).  Is there a reason for this change ? The other use of "IETF participants" later in the text sounds better.

"This maximizes the benefits the IETF derives from its core principles, such as its open process and volunteer core." Sounds really like a marketing statement to me...

Suggestion s/when language is inclusive or exclusive/whether language is inclusive/ to be consistent with previous sentence.

Having said this, let's continue to look for a more diverse and inclusive IETF community, which is more important.

Regards

-éric

[Ballot comment]
While I also agree with my co-ADs that any effort to make the IETF more inclusive is important (and I won't repeat everything Warren, Rob or Éric already said about supporting inclusivity efforts in IETF and aligning with other SDO's similar efforts) I don't think I can ballot anything else than Abstain. If there was a Recuse button, I would ballot that instead, but as there is not I am abstaining instead. There are mainly two reasons for this:

1. And most important - I have co-chaired gendispatch and shepherded the first proposal on this topic through the recommendation to create a WG (based on draft-gondwana-effective-terminology) [1], and although I have been as unbiased as possible, it would feel strange for me to approve on the chartering of this working group, while I also (together with my co-chair and AD at the time) evaluated the community consensus that lead to effort on chartering the working group.

2. Because I have followed the discussion on the topic very actively, if not since the beginning at least since its arrival in gendispatch at IETF108, I am concerned about the potential of this work to create divisiveness and hurt in the community, and I am worried about the potential of the working group of being destructive rather than constructive.

The conclusion is that I have a serious concern about this working group being chartered, but as my concern is not actionable, and as I stand behind my evaluation of consensus at the time of chairing gendispatch (after hearing the community speak in 1 meeting, 2 interims [2], and countless emails [3]), I will not block this effort. I however wanted to mark my opinion and make sure the resp AD and the whole IESG pays particular attention to its evolution.

Thank you Ben for summarizing the last set of comments we got on the charter. Additionally, as an actionable comment, I still think mentioning in the charter that draft-gondwana-effective-terminology is the starting point of this work might help.

Francesca

[1] https://mailarchive.ietf.org/arch/msg/gendispatch/iHDh7KBVRvGB2EWKYYh11LjP95E/
[2] https://datatracker.ietf.org/doc/minutes-108-gendispatch/
      https://datatracker.ietf.org/doc/minutes-interim-2020-gendispatch-01-202009012000/
      https://datatracker.ietf.org/doc/minutes-interim-2020-gendispatch-03-202009071100/
[3] https://mailarchive.ietf.org/arch/browse/gendispatch/?q=terminology (excerpt, I know there is more)

[Ballot comment]
Languages evolve. This  evolution depends  on lots of factors - the use, the time, the context, the events, the diversity -- this list is long here, also the evolution does not really happen through same mechanisms everywhere. Hence, the use and meaning of particular terminology or words will differ in different time context. Best possible strategy should be to try to use terminologies/words best suited for the job at hand. For IETF, that job at hand is to produces technical specifications. For such specifications the desire must be to avoid  ambiguity, offensiveness, exclusion (in whatever from) as much as possible.

There has been long discussions on the term charter and there has been concerns. I believe, this work on recommendation for effective and inclusive terminologies requires scrutiny to some extend to produce fruitful outcomes. Hence, I foresee term working group as a platform where discussions can happen, constructive feedback can be exchanged to produce consensuses to on terminologies to be used in the technical specifications paving way for more diverse and inclusive IETF. Thus, I have no object on approving this working group.

[Ballot comment]
I agree with many of Ben's and Warren's points.


Inclusion is not a yes/no proposition; it is a never-ending and always-changing road.  With that in mind, the focus should not be on "inclusive terminology" but on it being non-exclusionary.

"The principles should match the expectations from a diverse set of IETF participants."  Even though we've seen support for this effort, I am concerned that it won't necessarily translate into participation and contribution, especially from a "diverse set of participants."  This task won't be easy; the diverse composition of the WG should be an absolute requirement.

[Ballot comment]
I don't know if a WG is the perfect way to achieve the required outcome, but that was the consensus decision of the gendispatch process and the idea of punting this issue to the RFC editor was discussed and dismissed.  We have been discussing this for at least 9 months, and I think that changing tack and starting down a different path now will not go anywhere useful.  I.e., perfect is the enemy of good.

I also believe that most IETF participants wish to focus on producing technical standards, and are happy to use language that doesn't accidentally cause offense, and are either supportive or agnostic to the IETF providing guidance on what language should be used.

I hope that the members of the community who have concerns work constructively to try and find a consensus position within the TERM WG.

I support the chartering of this WG.

[Ballot comment]
While I am very skeptical whether any informational RFC will change anything or have any useful impact, let's go with the flow even if only to keep a common terminology with other SDO... Hence my 'no record' position...

Thanks for addressing my previous comments ;-)

Nevertheless, I am puzzled by the replacement of "work produced by IETF" by "work produced by IETF participants" because "IETF" includes the processes, BCP, etc. while "IETF participants" does not (at least for a non English speaker).  Is there a reason for this change ? The other use of "IETF participants" later in the text sounds better.

"This maximizes the benefits the IETF derives from its core principles, such as its open process and volunteer core." Sounds really like a marketing statement to me...

Suggestion s/when language is inclusive or exclusive/whether language is inclusive/ to be consistent with previous sentence.

Having said this, let's continue to look for a more diverse IETF community, which is more important.

Regards

-éric

[Ballot block]
Given the number of times the question was raised by the community, I would
like the IESG to actively come to a conclusion on whether an IETF WG is the
right venue for this work at this time, before approving the formation of a
WG.
(I do not expect to hold this as a blocking position after the IESG telechat.)

[Ballot comment]
I present my own comments (as shaped by the community feedback) on the
proposed charter text, followed by a summary of comments the IESG received.

> 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. IETF documents, including 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. This maximizes the
> benefits the IETF derives from its core 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 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

Given the difficulty in pinning down "inclusivity" (as compared to measuring
"exclusivity"), perhaps "have an exclusionary effect" is a more precise way of
expressing an equivalent question?

> 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.

Perhaps "benefit from advice and guidance on using effective terminology in
IETF documents while minimizing exclusionary effects"?

> The TERM working group is therefore chartered to produce an Informational RFC
> containing recommendations on the use of inclusive terminology in the technical

"advice and guidance" again?
I also am not sure about the word "inclusive" here.  It seems like it may have
value in that it is becoming an established term of art in some communities,
but what is lost if we just go with "on the use of terminology"?

> work produced by IETF participants. The RFC will express general principles for
> assessing when language is inclusive or exclusive. The principles should match

This seems like it may be a false dichotomy (though I do note that the word
"either" does not appear); some terms are neither inclusive nor exclusive.

> the expectations from a diverse set of IETF participants. The WG will identify

Is "should" an actionable requirement?

> and recommend an external, independently-updated resource containing examples of
> potentially problematic terms and potential alternatives to IETF participants,

I a little bit wonder whether the emphasis should be on the potential for
problems or on a recommendation for careful consideration prior to usage.
It may not matter in the end, though, but any way we can reiterate that this
is not a list of banned words is worth some consideration.

> in order 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 IESG got a significant amount of feedback on this proposed WG charter, and
I think it is valuable to try to synthesize that feedback into a somewhat
high-level (albeit extended) summary of the thoughts that were expressed by the
community.  I'm recording this here in my ballot position on the charter in
order to provide a record of the feedback that was received and as a reference
by which to evaluate the output of a WG (if approved).  Some of the comments
were sent directly to the IESG, and my initial notes did not track which
messages were also posted to terminology@ and/or ietf@, so I will not provide
attributions for the statements.  (Most of them are not direct quotes anyway,
and in a reassuringly large number of cases a similar sentiment was expressed
by multiple people and I have synthesized it into a consolidated
representation as part of the summarizing process.)

We got some "support with no comment", and some "oppose with minimal comment",
but as always, such opinions divorced from supporting reasoning does not add
much weight to a determination of consensus.  The main bulk of this writeup
focuses, accordingly, on the actual comments received.

Having constraints in the charter is useful.  There is a sizeable chunk of
work that looks attractive but we are not equipped to do properly and should
not try to do.

For work that is claiming to foster inclusivity, the effect so far just of
talking about the proposal has been rather divisive (i.e., counterproductive).
That might call into question whether the endeavor should be attempted at all,
but it is possible that the act of reaching consensus on a charter and
starting a WG can bring a fresh start to the discussions and move the focus
away from the particularly contentious matters that are not even listed as
deliverables in the charter itself.  On the other hand, though, we must
acknowledge that this work has the potential to destroy the IETF from within
if mishandled, and that there is additionally risk of organizational harm from
outside the IETF, if we attract the wrong kind of attention.  That said, we
got enough messages of support and indicating that the charter as written is
good enough to proceed that I am willing to have us attempt the experiment,
but expect the responsible AD to pay attention to how the work proceeds and
the milestone deadlines; if it ends up unworkable we should close the WG
rather than let it linger.

Looking further in the past for inspiration, we heard that one outcome from
POISSON was a desire to avoid broad/divisive topics if possible, and that
POISED was an interesting case where there was such a clear need to make a
change in how we work that seeing the change drive contributors, even prominent
ones, away was seen as an acceptable cost.  Such a consensus is not readily
apparent for the current terminology topic, so drastic change is probably not
a workable outcome.

As far as the output of this WG goes, it's more useful to offer broad
guidelines and patterns for use by document authors, so that we are equipping
authors to make their own decisions, rather than to give specific (and
potentially too narrowly scoped) advice on what to do or not do.  Analysis of
the landscape, explanation for why things are (dis)recommended, and guidance
are good to provide, but specific direction and rules should be avoided.  We
don't need the result of this WG to be an immediate drastic change in what we
produce, and it's best if the change is driven by individual participants and
authors as we go about our work.  In some cases, big change may not come about
until the next iteration of a spec or even the next protocol comes around, but
we will have a direction to work in.  The output should be advisory only, and
invidual WGs will remain in control of their output.

This is, of course, only one of many issues that we face; probably not even the
most important one.  The IETF's "rough and tumble" culture of sometimes
confrontational debates is probably a bigger barrier to inclusivity than the
terminology we use in our written output.  However, that doesn't mean we can't
or shouldn't think about it or that we shouldn't a priori take action on it,
even as we also take action on other fronts.

Looking further in the past for inspiration, we heard that one outcome from
POISSON was a desire to avoid broad/divisive topics if possible, and that
POISED was an interesting case where there was such a clear need to make a
change in how we work that seeing the change drive contributors, even prominent
ones, away was seen as an acceptable cost.  Such a consensus may not exist on
the current terminology topic.

We heard from many people that the charter text as-is is mostly reasonable,
but there are many potential pitfalls not listed in the charter that still
need to be avoided.  For example, don't create language police, don't make
recommendations about word usage that are too broad and exceed their scope of
applicability, and don't exceed the WGs scope of expertise, especially if
there are other parts of the IETF that would do better on one thing or
another.  The choice of chairs is especially important, both in their
neutrality and their ability to maintain focus and avoid devolving into proxy
debates on out-of-charter hot-button issues.

In addition to the WG chairs, the IESG as well must neutrally arbitrate
whether the process was followed, and not impose their own preferences.  For a
non-technical topic like this that has already seen controversy, even having
the same IESG that approved a WG be tasked with assessing its consensus could
be seen as problematic, especially if the WG approval process was swayed by
the IESG or IESG members.  It is most definitely not allowed for the IESG to
push through something that lacks community consensus, even if (as may have
happened for NEWTRK) the IESG might be within its rights to decline to publish
something that does have consensus or for which the consensus status remains
unknown.  The question of such heavy involvement of the IESG in a matter that
does not have many technical issues to adjudicate leads to a question of
whether other mechanisms for assessing consensus could be used for this group
or this topic, including whether an IAB program or RFC Editor-driven activity
might be more appropriate.  This topic was raised and endorsed by many people.
While we have a pretty clear answer that the IETF stream *can* choose to apply
more stringent rules than the RFC Series as a whole, the question of whether
or not we *should* seems a little under-addressed.  A couple of people replied
on this topic specifically supporting doing the work (now) in the IETF, but
many fewer people than were participating in the overall discussion.  In a
related note, the concern was raised that having the IETF present a fait
accompli here might constrain the work of the ongoing RFCEFDP activity, which
is supposed to be a broader scope than just the IETF.  In a related vein, it's
possible that RFCEFDP itself could lead to the emergence of a stronger RFC
Editor function with a mandate to push back on the streams and actually apply
editorial judgment.  Such an RFC Editor function might be well placed to
effect change on the terminology front and obviate the need for an IETF WG,
but we don't have much way of knowing whether we will get such an RFC Editor
function.

TERM is not really a technical group in our usual sense, as is acknowledged by
the previous paragraph.  Yet there is also risk that for work in this space,
an informational document will end up being a de facto BCP that is enforced
just as strongly as any process BCP we produce, and we have ample reason to be
concerned about falling into a scenario (regardless of exactly how) where
there is active control being imposed over what terminology is used and
policing to enforce it.  No matter what kind of caveating language we might
put alongside it, having any kind of list of "bad words", whether internal or
externally maintained, poses risk of authoritarianism and a bad outcome
despite good intentions.

This leads to the question: do we want to maintain a list of terms, whether
general or focused to our particular expertise and then augmented by a more
generic list?  Do we want to use a list of terms at all?  If there is to be a
list of terms, it should be picked based on community consensus, unswayed by
the IESG.  If maintaining a list of terms is to be out of scope for the WG,
that should be clearly and explicitly stated in the charter (Lars thinks that
the IETF maintaing a list of terms is intended to be out of charter for this
WG).  Interestingly, there is already a list at
https://github.com/ietf/terminology (not maintained by this not-even-a-WG, of
course), and it seems unlikely to go away and should probably get some further
disclaimer or a path towards actual maintenace and official status.  My
understanding is that the github repository is not proposed to be a WG
activity in the current charter, but this is still a good time to think about
its long-term status.

We are behind the curve compared to other SDOs and companies.  This is not
inherently bad, but we should probably default to the trodden path and only
diverge when we have strong justification, even if some other option might be
better in a narrow sense.  There is value in alignment with other groups, for
efficiency of communication among other reasons, though just as we do not
rubber-stamp external technical specs, we should also be able to justify our
choice if we adopt externally developed approaches on the terminology front.

In a charter for a group about terminology, the specific terms in the charter
seem like they may merit further consideration.  What is "inclusive", after
all?  Most of what we discuss is about avoiding known sources of exclusivity,
but merely avoiding exclusivity does not itself bring inclusivity.  Likewise,
what is "effective"?  Effective at conveying technical intent, or effective at
being inclusive, or both?  "Recommended", for this audience, has connotations
of BCP 14 language, but perhaps we really only intend to offer advice and
guidance.  Is it in scope to discuss what terms with "cultural baggage" might
be unevenly accessible to IETF participants?

[Ballot comment]
I agree that we should not be using terms that are, or could be, offensive, hurtful or send discouraging signals. I also believe that the vast majority of people in the IETF who do use terms like this are doing it unthinkingly, and without malice. These two precepts lead to the “it would be good if we had a resource where we would learn about terms which may be offensive, and easy replacements for those terms”. So far, so good….

In addition, I’m very supportive of building an IETF where anyone, and everyone, feels comfortable and welcome participating. The question for me is not whether this should be done, but rather what is the most effective, inclusive, ground-up method that will have the most buy-in and be the easiest to build upon further.

I don’t think that a working group is the right way to accomplish this - I oscillated between Abstain and NoObj, and finally settled on NoObj because I want to be clear that I do take the problem itself seriously. People should *want* to treat each other well, and anything “official” created by the IETF (like a WG) seems, to me, like it doesn’t solve the root problems, and probably makes them worse.  I understand that this WG is “chartered to produce an Informational RFC containing recommendations on the use of inclusive terminology in the technical work produced by IETF participants.”, and that this is supposed to “complement other efforts at fostering inclusivity in the IETF”.  My concern is that this approach will simply further polarize the community, and will lead to more division and antagonism.  Telling someone they are bad and must change doesn’t generally work; it generally makes them feel like they are being judged, become defensive, and attempt to justify, if not perpetuate, those behaviors. Helping them understand why their actions may be considered harmful  seems much more useful and likely to result in a positive change.

Even if we were to magically remove all terms which might cause offense to someone, I don’t think that that fixes our inclusivity issues, and, based upon the fact that we clearly have some set of people who are trolling for a fight, I think it makes things worse.

I would much rather that we instead work on actually addressing the inclusivity problems and treat the malady and not just the symptoms. More focus/resources on newcomers, meetings in more countries, discounts for first time attendees (and better student support), plenaries on inclusivity (and understanding other cultures!), more focus on things like GAIA, etc all seem (to me!) useful.

There are already resources for people who want to improve - anything “official” like an IETF WG / RFC is (in my opinion) likely to just trigger the trolls and give them more of a platform. For potential newcomers to the IETF, I’d prefer the larger “most of us are actually nice people” context to be in the forefront, instead of a loud, unpleasant, minority. In summary, I’m all for helping people understand why some terms are hurtful/harmful - but I don’t think that the current way we are trying to accomplish this works…

I understand that I’m in the rough here. I understand that (and why) many want this chartered. I’m not trying to block progress, I just don’t think that this is is going to make things better…  but I will not stand in the way of those who do.

[Ballot comment]
I'd suggest s/judging/assessing/ in the vein of what was noted already.

It's not clear that work in this space is properly a "one and done"
exercise vs a continuing endeavor to adapt as situations change.  That
said, having a single immediate concrete goals does seem wise as a
start.

[Ballot comment]
While I am very skeptical whether any informational RFC will change anything or have any useful impact, let's go with the flow...

I have two comments though:

"The RFC will express general principles for *judging* when language is inclusive or exclusive. ", can we replace 'judging' by something else ? Suggest 'evaluating'

"The principles should match the expectations from *a broad set* of IETF participants.", what is the semantic of "broad" here? Does this mean 50% of the participants? 50% of the vocal participants ? Coming from a country, Belgium, where even 5% of population can rightfully block some legislations, I would prefer some text about 'diversity' (that itself is also fuzzy). For example, it seems that some Italian people do not appreciate the wording "spaghetti code" (and I can understand them) even if IETF participants from Italy is probable less than 5%.

-éric

[Ballot comment]
This is very timely and necessary  work, thanks for chartering it.

I think the charter should clarify if the working group outcome will impact only the future technical documentations or this might lead to changes in existing technical documents where non-inclusive terminologies are used (as per the recommendation by the working group)

[Ballot comment]
I don't think that using rfc7322 as justification/background for this work is needed or appropriate.  rfc7322, while very useful, is not an IETF consensus document.

Also, the output of this work should not be to recommend any action to be taken by the RPC; the authors should act on the recommendations.  Taking the rfc7322 reference out may also remove any potential assumption that the RPC should be involved.

[Ballot comment]
Thank you for chartering this work.

The charter is unclear if terminology that is not related to inclusivity is in-scope or not. For example, the QUIC documents use a concept of off-path attacker that is a little different from the meaning that I thought was commonly held.

I have no strong feeling on whether or not it should be in scope, but the charter should be clear about this.