Subject: [Terminology] Benjamin Kaduk's Block on charter-ietf-term-00-03: (with BLOCK and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 08 Apr 2021 02:32:48 -0700

Benjamin Kaduk has entered the following ballot position for
charter-ietf-term-00-03: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-term/

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

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