Re: WG Review: Effective Terminology in IETF Documents (term)

[John C Klensin <[e-mail]>]

Jari (and Brian),

Many messages have gone by since the one below, but it seems
like the right one to which to respond nonetheless.  Inline...

--On Tuesday, April 13, 2021 19:44 +0300 Jari Arkko
<[e-mail]> wrote:

> Brian,
> 
>> I believe that the charter is good enough as it is, but I
>> also believe that the IESG should consider not only whether
>> there is consensus on the charter text, but also the basic
>> question whether this issue should be handled by the IETF at
>> all, rather than by the RFC Editor. 
> 
> I think that's a good question.
> 
> I have a view on that, and interestingly I came to a different
> conclusion than you did. Perhaps it would be useful to talk
> about this a bit further.
> 
> So, my reasoning is that the right place for most IETF
> decisions is at the working groups. (Subject to some common
> policies and full IETF review, of course, as discussed in the
> other thread…)

So, should a WG doing technical/substantive work have
responsibility for the documents it is producing (subject to
your qualifications)?  Absolutely and I don't think anyone has
proposed otherwise.

I think this is correct for IETF technical work, i.e., about
Internet protocols and related work to make the Internet work
(or work better).  But this topic and the proposed TERM WG do
not fall into that category.  I've described the problem in the
context of the RFC Editor Future discussions as one of
expertise: it is much better if work is done by, and evaluated
by, people who actually have expertise in the subject matter
(and who know what they don't know) rather than perhaps only
having strong opinions.  

As an extreme example, if someone came to the IETF and said, "We
need to standardize treatment regimes for COVID-19 and databases
for keeping track of vaccinations and disease patterns.  Because
the data will be transmitted over the Internet, we think the
work should be done in the IETF".  I hope (and believe) we would
say "insufficient expertise about the subject matter here" and
encourage them to go elsewhere or, if there were special,
Internet-specific issues, we would try to work out some
arrangement by which we could advise, e.g., WHO without needing
to develop expertise in (that type of) viruses or medicine.  We
would not be having a discussion about exactly what words to put
in a charter, especially a charter for a WG whose creation seems
to be assumed in the way the discussion was framed.  The
situation with TERM is, I hope obviously, not quite as extreme
as the medical one but it seems too close for comfort.

> I could imagine RFC Editor adjusting text in a security
> considerations section that talked about some filtering and
> used older versions of "denylist" in the text. But I'm
> not sure I'd want the RFC Editor to adjust a major term
> picked by a working group in their protocol, particularly when
> the change may cause differences between a new RFC and older
> RFCs to occur. I'd want the WG to make that determination.
> For an example, see
> https://tools.ietf.org/html/draft-ietf-tls-rfc8446bis-00#secti
> on-1.2
> <https://tools.ietf.org/html/draft-ietf-tls-rfc8446bis-00#sect
> ion-1.2> 

I share your concern for the RFC Editor simply adjusting text.
But I don't think anyone who has thought this through seriously
considers what were described several days ago as applying
   s/bad-term/new-term/ 
changes globally.    Instead, I would expect something much
closer to what I have experienced for years (and assume you
probably have too):  notes saying in some way "would this be
better if we replaced <term-or-phrase-A> with
<term-or-phrase-B>?" followed, if needed, by a discussion. 

Would it be better to get a collection of problem terms into
some sort of list with possibly better ones and attach that to
the style manual in the hope (and expectation, however
unrealistic) that WGs (or other document sources) would sort
things out long before they got to the RFC Editor?  Yes, of
course.  But that is really no different from a preference for
good-quality American English over a variety of other languages
and dialects that approximate such English, documents that are
then dumped on the RFC Editor: If those things get through IETF
LC and the IESG signs off, the "editing" process includes a good
deal of discussion between RPC staff and authors and, often, WG
Chairs and ADs and, at the discretion of those in the IETF
sign-off chain, the WGs themselves [1].

> All this leads me to believe that the WGs are and should be in
> charge of the bigger modifications. 

Ok.  But that is really no different from any other problematic
language, document organization, or phrasing.   For whether the
WGs should be more involved in that part of the editing process
rather than implicitly delegating it to authors as has been
usual in the past, see note [2].

> This still leaves room for:
> 
> - a new terminology working group to provide guidance &
> principles

And I thought that was what we are talking about here, except
that I would have preferred that you say "terminology effort".
See below.

 - RFC editor to check and adjust text (and possibly
> highlight issues back to the authors)*

Right.  See above.

>...
> *) Lars' working group proposal does not involve the working
> group actually developing a list of terms. That too could
> possibly be a thing that the RFC Editor could do. But of
> course the community could do it also, as volunteers in some
> design-team like activity, or we could find an entirely
> external resource that is updated with information.

Yes.  But, if the TERM WG neither develops a list of terms (see
below) nor has responsibility for document-by-document decisions
about terminology (which would make it less a WG than some sort
of special committee of the IESG and/or the RFC Editor of the
likes we have never had before), why do you think a WG is the
right structure for that work?  Put differently, if the core
things TERM is going to do could be done by a "design-team like
activity", what do we need TERM for.   There is no evidence that
the participants such a WG would attract would be expert in
choices of terminology or in balancing tradeoffs unique to the
IETF or particular protocols or documents.  If the main task is
to gather up vocabularies and mapping thesauri compiled by
others, that doesn't sound to me like a task for an open WG in
which anyone can voice their opinions and/or the perceived
grievances of others.  Instead, it would seem much better and
more efficient to do exactly what you suggest-- appoint a group
with a reasonable balance of expertise --whether we call that a
design team, a short-lived directorate, or something else-- make
sure the RFC Editor (including both the Production Center and
whatever substitute we might temporarily invent for an RSE) is
represented in those discussions, and then produce
recommendations and how those should be made available to the
community.   At least today, I'd personally favor extending the
Style Manual and I note that even new versions of the style
manual get community requests for input and review.   If the
real value of a WG is that the IESG gets final say on its
output... well, with no disrespect to their skills in other
areas, it is not clear either that the IESG has the necessary
expertise in this area or even that it falls within their
charter.

best,
   john

p.s. I think the view expressed above is somewhat different from
Stewart Bryant's in 
https://mailarchive.ietf.org/arch/msg/ietf/WASouhKP24ay_n2GtrxP2YRj718
but they probably lead in the same direction.

[1] I think one result of this effort, with or without the TERM
WG (or an alternative) and whatever they might propose, is going
to be more work for the IESG, the RFC Editor process, or both.
I hope we are all ready for that, including the LLC for the
financial implications and for the IESG having to make decisions
that balance reviews for better terminology with consideration
of technical quality issues that would exist regardless of the
terminology.  

[2]  Do I think many more documents should be sent back to WGs
by either the IESG or the RFC Editor with "please sort this out"
notes?  Do I think that changes "approved" in AUTH48 ought to go
back for a check on WG Consensus and maybe even IETF Last Call
far more often than we do that?  Yes to that to.  But it seems
to me that we should strive to keep those separate subjects even
if I think you suggestion about WG control leads quickly in that
direction.