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

From: S Moonesamy <[email-masked]>
Date: Thu, 01 Apr 2021 02:47:58 -0700

Dear Internet Engineering Steering Group,

There was an announcement for the WG review of TERM {1].  There was a 
saying of what was likely a general truth in 1992 which is documented 
in the Introduction Section of RFC 7282: "We reject: kings, 
presidents and voting."  The word "king" is defined in a dictionary 
(United States) [2] as "a male monarch of a major territorial 
unit".  Is it within the scope of the proposed working group to 
determine whether that word/saying is inclusive or exclusive?

The draft charter mentions "informational recommendations". The 
terminology is ambiguous as it could be interpreted as meaning that 
the objective of the proposed working group product is to provide 
information or that the objective is to make recommendations.

The draft charter mentions "industry initiatives".  Will the working 
group coordinate with industry initiatives from the United States 
and/or Europe only?

Regards,
S. Moonesamy

1. 
https://mailarchive.ietf.org/arch/msg/ietf-announce/6yVtXkj3wJjQxQA29On8-Lyvwmw/
2. https://www.merriam-webster.com/dictionary/king

---

From: Lars Eggert <[email-masked]>
Date: Thu, 1 Apr 2021 13:02:29 +0300

Hi,

On 2021-4-1, at 12:47, S Moonesamy <[email-masked]> wrote:
> There was an announcement for the WG review of TERM {1].  There was a saying of what was likely a general truth in 1992 which is documented in the Introduction Section of RFC 7282: "We reject: kings, presidents and voting."  The word "king" is defined in a dictionary (United States) [2] as "a male monarch of a major territorial unit".  Is it within the scope of the proposed working group to determine whether that word/saying is inclusive or exclusive?

not in my reading, since the charter says the document the WG will produce should "express general principles for
assessing when language is inclusive or exclusive".

(I'll also note that the text from RFC7282 is in fact a quote from a plenary presentation from 1992.)

> The draft charter mentions "informational recommendations". The terminology is ambiguous as it could be interpreted as meaning that the objective of the proposed working group product is to provide information or that the objective is to make recommendations.

I don't see this ambiguity, but I'm happy to change "informational recommendations" to "recommendations", if that is clearer?

> The draft charter mentions "industry initiatives".  Will the working group coordinate with industry initiatives from the United States and/or Europe only?

The charter isn't constraining the WG in this regard.

Thanks,
Lars

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 1 Apr 2021 12:09:04 +0100

S Moonesamy wrote on 01/04/2021 10:47:
> saying of what was likely a general truth in 1992 which is documented in 
> the Introduction Section of RFC 7282: "We reject: kings, presidents and 
> voting."  The word "king" is defined in a dictionary (United States) [2] 
> as "a male monarch of a major territorial unit".  Is it within the scope 
> of the proposed working group to determine whether that word/saying is 
> inclusive or exclusive?

Maybe we could change the term "kings" to "princes", as this would be 
more geographically inclusive?

I've been contacted by many princes over the years from all over the 
world the world, all whom seemed to be interested in giving me money, if 
only I could provide certain personal details.

Nick

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 1 Apr 2021 08:04:59 -0400

S. and Lars,

I was at that plenary presentation. The obvious intention of Dave's quote
is that we reject "monarchs", but it is true that the word used at the time
(again, this was 1992) was "kings". But RFC 7292 also makes it clear that
this is a direct quote from Dave's presentation.

But that really has nothing to do with the proposed charter, which says
that the purpose of the WG is to "produce an Informational RFC containing
recommendations on the use of inclusive terminology in the technical work
produced by IETF participants". What's not in the charter of that WG is to
go back and review the language in every existing RFC.

Once the WG's work is done, and there's such an RFC, anyone is free to use
it to propose errata on existing RFCs and comments on other ancillary IETF
material, such as its web pages, the Tao, and so on. A new WG could even be
chartered at that time to do this sort of thing.

But I don't see how this has any effect on the proposed charter at hand.

Cheers,
Andy

On Thu, Apr 1, 2021 at 6:03 AM Lars Eggert <[email-masked]> wrote:

> voting."  The word "king" is defined in a dictionary (United States) [2] as
> "a male monarch of a major territorial unit".  Is it within the scope of
> the proposed working group to determine whether that word/saying is
> inclusive or exclusive?
>
> terminology is ambiguous as it could be interpreted as meaning that the
> objective of the proposed working group product is to provide information
> or that the objective is to make recommendations.
>
> I don't see this ambiguity, but I'm happy to change "informational
> recommendations" to "recommendations", if that is clearer?
>
> group coordinate with industry initiatives from the United States and/or
> Europe only?
>

---

From: S Moonesamy <[email-masked]>
Date: Thu, 01 Apr 2021 05:40:01 -0700

Hi Lars,
>recommendations" to "recommendations", if that is clearer?

Yes, thanks.

Regards,
S. Moonesamy

---

From: Michael StJohns <[email-masked]>
Date: Mon, 5 Apr 2021 19:11:08 -0400

For some reason I can't find the original announcement, so I'll just do 
this bare.

Given the general language of RFC 2418, my best take is that _*it's 
inappropriate for the IETF to charter a working group on this topic*_.   
It's not a technical topic, and it does not fit the general WG model.

To my best recollection (which means I may have missed one), we've never 
chartered a WG solely for the purpose of writing documents that purport 
to modify the way the IETF does business. Such documents have usually 
come either as IESG / IAB authored/sponsored BCPs.  Indeed, BCP 95 was 
just such a document.   WGs have been (should be?) for technical 
activities related to specifying how the Internet works.

<minirant>Technical WGs at least have the possibility of achieving 
consensus based on the analysis of tradeoffs of hard facts and good 
analysis.  A "WG" such as TERM may fail of achieving even WG consensus, 
let alone community consensus (especially given the current ongoing 
discussions) and there will be no fall back to fact analysis possible.   
I can't see any way an appeal could be managed in those circumstances 
and I strongly suggest we do not try to place this in the WG 
model.</minirant>

Since the proposed charter for Term will effect more than just the 
standards process (e.g. it potentially effects all of the current and 
future RFC streams), it would appear this should be handled either as an 
IAB activity (either authored, or referred to a workshop), or deferred 
until the RFCED group completes its work and can have this assigned as a 
work item.

My first preference is to do this as an IAB Workshop report with no BCP 
tag and with as dispassionate an analysis and output language as 
possible.  E.g. explanatory language vs directive.

Mike

---

From: Michael StJohns <[email-masked]>
Date: Mon, 5 Apr 2021 19:31:11 -0400

On 4/5/2021 7:11 PM, Michael StJohns wrote:
>
> For some reason I can't find the original announcement, so I'll just 
> do this bare.
>
>
> inappropriate for the IETF to charter a working group on this 
> topic*_.   It's not a technical topic, and it does not fit the general 
> WG model.
>
> To my best recollection (which means I may have missed one), we've 
> never chartered a WG solely for the purpose of writing documents that 
> purport to modify the way the IETF does business.
>
*sigh* Ignore the above. Joel H reminded me of Poised, Poisson of the 
previous century and Newtrk of the previous decade.   I'm sure there are 
others.

> Such documents have usually come either as IESG / IAB 
> authored/sponsored BCPs.  Indeed, BCP 95 was just such a document.   
> WGs have been (should be?) for technical activities related to 
> specifying how the Internet works.
>
> analysis.  A "WG" such as TERM may fail of achieving even WG 
> consensus, let alone community consensus (especially given the current 
> ongoing discussions) and there will be no fall back to fact analysis 
> possible.   I can't see any way an appeal could be managed in those 
> circumstances and I strongly suggest we do not try to place this in 
> the WG model.</minirant>
>
> future RFC streams), it would appear this should be handled either as 
> an IAB activity (either authored, or referred to a workshop), or 
> deferred until the RFCED group completes its work and can have this 
> assigned as a work item.
>
> My first preference is to do this as an IAB Workshop report with no 
> BCP tag and with as dispassionate an analysis and output language as

---

From: Lucy Lynch <[email-masked]>
Date: Mon, 5 Apr 2021 17:00:20 -0700

> On Apr 5, 2021, at 4:31 PM, Michael StJohns <[email-masked]> wrote:
> 
> 
>> For some reason I can't find the original announcement, so I'll just do this bare.
>> 
>> 
>> 
>> Given the general language of RFC 2418, my best take is that it's inappropriate for the IETF to charter a working group on this topic.   It's not a technical topic, and it does not fit the general WG model.
>> 
>> To my best recollection (which means I may have missed one), we've never chartered a WG solely for the purpose of writing documents that purport to modify the way the IETF does business. 
>> 
> *sigh* Ignore the above. Joel H reminded me of Poised, Poisson of the previous century and Newtrk of the previous decade.   I'm sure there are others.
> 
> 
> 

And the late and unlamented Problem-Statement which produced two RFCs
(3774 and 3844) I’m sure Melinda and Harold still bear a few scars.

>> Such documents have usually come either as IESG / IAB authored/sponsored BCPs.  Indeed, BCP 95 was just such a document.   WGs have been (should be?) for technical activities related to specifying how the Internet works. 
>> 
>> <minirant>Technical WGs at least have the possibility of achieving consensus based on the analysis of tradeoffs of hard facts and good analysis.  A "WG" such as TERM may fail of achieving even WG consensus, let alone community consensus (especially given the current ongoing discussions) and there will be no fall back to fact analysis possible.   I can't see any way an appeal could be managed in those circumstances and I strongly suggest we do not try to place this in the WG model.</minirant>
>> 
>> Since the proposed charter for Term will effect more than just the standards process (e.g. it potentially effects all of the current and future RFC streams), it would appear this should be handled either as an IAB activity (either authored, or referred to a workshop), or deferred until the RFCED group completes its work and can have this assigned as a work item.
>> 
>> My first preference is to do this as an IAB Workshop report with no BCP tag and with as dispassionate an analysis and output language as possible.  E.g. explanatory language vs directive.
>> 
>> Mike
>> 
>> 
>> 
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 5 Apr 2021 19:10:33 -0500

On 4/5/21 18:31, Michael StJohns wrote:
>> topic*_.   It's not a technical topic, and it does not fit the 
>> general WG model.
>>
> previous century and Newtrk of the previous decade.   I'm sure there 
> are others.
>

Yeah, it's pretty much every working group that has ever formed in the 
GEN area:

https://datatracker.ietf.org/group/concluded/#WGs-general-area

/a

---

From: Lloyd W <[email-masked]>
Date: Tue, 6 Apr 2021 10:27:24 +1000

I agree: TERM will not be a technical workgroup, and will not be conducting technical discussion.

It's worth noting that TERM is specifically being chartered initially to produce an INFORMATIONAL document sans BCP tag, which sort-of gets around the BCP would-affect-all-IETF problem. Why, those aren't recommendations at all. Not binding on the IETF or how it works. Nothing to see here.

I'm sure we can all think of documents, throughout history, that started out as simply for information, and turned into something else entirely. And I'd like to point out the CAPS standards keywords used  throughout draft-knodel-terminology, which are not at all appropriate in informational documents that cannot make such recommendations. Really, starting out as informational is a minor speedbump on the road to success, and the controlling aspirations of that document are quite clear.

Establishing the TERM workgroup gives Niels and his colleagues a space in which to practise and better their authoritarian thought policing (sorry, 'governance'), out of the general view, in a safe area away from disturbance. Think of TERM as the Protocol Police Academy. They're citizens on patrol!

If you have opinions on TERM's formation, please do submit them to [email-masked] before that deadline. Today.

thanks

Lloyd Wood
[email-masked]

> On 6 Apr 2021, at 09:12, Michael StJohns <[email-masked]> wrote:
> 
> 
> To my best recollection (which means I may have missed one), we've never chartered a WG solely for the purpose of writing documents that purport to modify the way the IETF does business.  Such documents have usually come either as IESG / IAB authored/sponsored BCPs.  Indeed, BCP 95 was just such a document.   WGs have been (should be?) for technical activities related to specifying how the Internet works. 
>

---

From: Adam Roach <[email-masked]>
Date: Mon, 5 Apr 2021 19:46:38 -0500

On 4/5/21 19:27, Lloyd W wrote:
> And I'd like to point out the CAPS standards keywords used  throughout 
> draft-knodel-terminology, which are not at all appropriate in 
> informational documents that cannot make such recommendations.

Not terribly relevant to the TERM working group; but just to help people 
understand how things work around here: there are 1,099 existing 
informational RFCs that implicitly disagree with Lloyd's characterization.

rfcs$ egrep --files-with-matches 
"(MUST|SHOULD|MAY|OPTIONAL|RECOMMENDED)" `grep --files-with-matches 
INFORMATIONAL rfc*.json | sed s/json/txt/` | wc

...
     1099    1099   13188

/a

---

From: Michael StJohns <[email-masked]>
Date: Mon, 5 Apr 2021 22:10:02 -0400

On 4/5/2021 8:10 PM, Adam Roach wrote:
>>> never chartered a WG solely for the purpose of writing documents 
>>> that purport to modify the way the IETF does business.
>>>
Go take a detailed look at that list.  Roughly 1/2 of them are BOFs that 
never produced anything, roughly 1/4th are WGs that mostly didn't 
produce anything (unclear if the IDs they produced resulted in RFCs).  
The remainder were targeted groups that were dealing with moving us from 
a known point A to a known point B. E.g. we knew what what we needed to 
do, we were pretty sure we knew the neighborhood where we needed to 
arrive, we just weren't sure how to do it.

I'd place IASA2, the multiple instantiations of the Nomcom process 
(poised, poisson, nomcom), ianaplan, mtgvenue and the IPR groups in that 
last category.   IASA2, ianaplan and mtgvenue are all recent creations.  
Finally, IASA2 and ianaplan had some hefty legal requirements driving them.

TERM has few of those characteristics: there's no agreement on where 
point B needs to be and not a lot of agreement on where point A actually 
is.

But yes, my initial statement was way off.

Later, Mike

---

From: John C Klensin <[email-masked]>
Date: Tue, 06 Apr 2021 00:08:55 -0400

>...
>> Given the general language of RFC 2418, my best take is that
>> _*it's  inappropriate for the IETF to charter a working group
>> on this  topic*_.   It's not a technical topic, and it does
>> not fit the general  WG model.
>...
>  Joel H reminded me of Poised, Poisson
> of the previous century and Newtrk of the previous decade.  
> I'm sure there are others.

I know you remember and probably bear some scars, but, for those
who don't, POISED was very special, occurring when there was
very broad consensus that there was a problem that needed to be
solved in order for anything else to move forward in the IETF
ever again.  It defined the contemporary IETF and its structure
and, while I don't remember it being said explicitly, I think
there was fairly broad agreement that it was ok if people, even
fairly significant contributors, didn't like the result, went
away, and didn't come back.  

Independent of any other issues, I don't see there being
sufficient consensus over this issue that it is worth driving,
not just participants but  significant contributors, out of the
IETF would be an understatement.  More on that below.

There was also POISED95, which, among things, sorted out and
produced RFC 2026, 2027 (the foundation for the contemporary
NOMCOM model), 2028 (which we have never gotten around to
updating -- see the discussion at GENDISPATCH last month), and
2031 (which more or less defined the IETF-ISOC relationship
until the LLC came along).

Having co-chaired POISSON, while I would claim the effort was
mostly successful, it was also painful: the charter said "This
is therefore a slippery subject,
hence the name POISSON, which is French for fish." and I claim
that, like dead fish, some of the work took on a bad odor and
taught us the importance of the previous sentence of the
charter: "The tricky part of describing the IETF process,
certainly in the fast changing world of the Internet, is that
when you describe the process in too much detail, the IETF loses
its flexibility, when you describe to little it becomes
unmanageable." and, while, like its two predecessors, there was
strong consensus about the importance of the work and the desire
to get it done, I think, tuning aside, there was also fairly
strong consensus to tune existing procedures when necessary in
the future (the periodic revisions to the Nomcom and appointment
model are good examples) but to avoid taking on broad topics,
especially ones with the potential to seriously divide the IETF
and leave it divided or with people leaving, if at all possible.

I agree with Lucy about Problem Statement as well.  

Despite having community consensus that the problems it intended
to address were important, I watched NEWTRK leave scars that
have not healed.  Others would probably disagree, but I suggest
it demonstrated the willingness of the IESG to decide that its
experience and perspective in IETF process matters were more
valid and important than the consensus of the WG, so much so
that there was no reason to try to ascertain IETF rough
consensus before dismissing the WG's key results without an IETF
Last Call.  I have no reason to believe the current IESG would,
or even might, do that but, to the extent to which the IESG has
proposed this as a WG, if it is going to be chartered as a WG,
it would be very desirable to design a different mechanism for
managing Last Calls and evaluating community consensus than the
same IESG.    And that is probably just another argument for
"not as an IETF WG".

>...
>> <minirant>Technical WGs at least have the possibility of
>> achieving  consensus based on the analysis of tradeoffs of
>> hard facts and good analysis.  A "WG" such as TERM may fail
>> of achieving even WG  consensus, let alone community
>> consensus (especially given the current ongoing discussions)
>> and there will be no fall back to fact analysis 
>> possible.   I can't see any way an appeal could be managed
>> in those  circumstances and I strongly suggest we do not try
>> to place this in  the WG model.</minirant>
>> 
>> Since the proposed charter for Term will effect more than
>> just the  standards process (e.g. it potentially effects all
>> of the current and  future RFC streams), it would appear this
>> should be handled either as  an IAB activity (either
>> authored, or referred to a workshop), or  deferred until the
>> RFCED group completes its work and can have this  assigned as
>> a work item.

I would go a bit further.  Because responsibility for
determining the appropriateness of vocabulary in the RFC Series
has traditionally been the responsibility of the RFC [Series]
Editor (going more or less back to the beginning of Jon Postel's
administration and continuing through Heather's), launching this
effort now would likely have the effect of adding an unneeded
additional impediment to the RFCED group reaching consensus on
its core tasks and/or setting us up for additional future work
to harmonize the two.

>> My first preference is to do this as an IAB Workshop report
>> with no  BCP tag and with as dispassionate an analysis and
>> output language as  possible.  E.g. explanatory language vs
>> directive.

Agreed.  There is no doubt in my mind that we have language and
terminology problems, especially when those are considered
broadly and cross culturally.  I think it is reasonable and
appropriate that we do as much as possible to educate the
community, and especially would-be I-D or RFC authors, about the
issues.  That requires analysis, explanation, and guidance, not
directions or rules (and especially not directions or rules on
which we will not be able to agree and that will cause further
divisions in the community because of the lack of agreement.  I
think it is also reasonable and appropriate for people who find
what they think is inappropriate language in a draft in a WG or
submitted for Last Call to raise those issues, both in the hope
of getting the language fixed and to facilitate education of the
authors.   But, if there are any lessons from any of our recent
efforts in WGs designed to specify important aspects of the
standards process or from the intensity and tone of the recent
discussions of terminology on the IETF list, those lessons are
that there is no community consensus (even rough consensus) that
this work should be done in a way that would (or might)
establish specific directions for vocabulary or behavior and
that, absent such consensus, the results are as likely to be
destructive as helpful.

best,
   john

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 6 Apr 2021 07:03:55 +0200

On 6. Apr 2021, at 06:08, John C Klensin <[email-masked]> wrote:
> 
> establish specific directions

Wikipedia has a category of content called “original research” (which is ruled out in Wikipedia articles).
This was established to keep a lid on what is best described as “crackpot science”.
It is now a more general guideline that sometimes gets in the way (2 * 2 = 4 is not really “original research”), but overall has served Wikipedia well.
It seems to me the current charter proposal text is trying to go into a similar direction, which might help a lot with keeping rough consensus attainable.
(And, of course, promptly it is attempted to weaken those guide rails...)

Grüße, Carsten

---

From: Nico Williams <[email-masked]>
Date: Tue, 6 Apr 2021 10:29:31 -0500

On Tue, Apr 06, 2021 at 12:08:55AM -0400, John C Klensin wrote:
> [...]

I think this is the most helpful message yet on this topic.  I'm afraid
that my saying so might cause others to ignore it, but I hope that's not
the case.

> same IESG.    And that is probably just another argument for

There is a big difference between the IESG saying "we will not go
forward with this work in spite of it having WG and possibly IETF
consensus" and the IESG saying "we must go forward with this work in
spite of it lacking consensus".  The former is painful but within the
IESG's privilege.  The latter is outside the by-laws of the
organization.  The IAB would be a better body for pursuing publication
of work that lacks IETF consensus, would it not?

> >> RFCED group completes its work and can have this  assigned as

Ah, I'm hardly the first to think the IAB is a better home for this.

> its core tasks and/or setting us up for additional future work

Yes.  I would be perfectly happy and content with the RSE questioning
the use of the terminology in question in I-Ds on the RFC-Editor queue.
I would be perfectly happy and content with the RSE disallowing the use
of various terminology in I-Ds on the RFC-Editor queue.
And I've said so before.

One of the many reasons to prefer this approach is that it allows the
RSE great flexibility, which -considering how painful this process has
been thus far- should be highly desired as new terminology controversies
arise.

> that, absent such consensus, the results are as likely to be

+1

Nico
--

---

From: Jari Arkko <[email-masked]>
Date: Tue, 6 Apr 2021 23:00:37 +0300

> It seems to me the current charter proposal text is trying to go into a similar direction, which might help a lot with keeping rough consensus attainable.

I agree.

For what it is worth, I’m supportive of creating this working group. Of course it is only one effort among many things — most of them technical — and the terminology questions are one concern among dozens or hundreds of other issues. Internet has many issues. This doesn’t mean we shouldn’t address these questions or the other issues.

I believe the right way to approach this particular issue in the IETF is largely at the grass root level and focusing on improvements more than mandates. That is, we do useful things at the working groups and by individuals who should decide what they need to do with their documents; they are the experts, they own the problem space, etc. In some cases good terms can be found that are better and more descriptive than some previously used terms; we should opt to use those. And, change is a long-term process. I can maybe have an effect on the terminology in the next iteration of my working group’s spec. Or perhaps only the next protocol.

The above doesn’t mean the IETF shouldn't keep this issue in mind, or that no working group is needed. As (for instance) draft-gondwana-effective-terminology put it, “engineering takes priority; decentralised control; centralized knowledge”. I would be happy for us to state something like that, and keep pointing to resources where WGs can look up various best practices regarding terminology.

I think the proposed charter is doing largely what I describe above. A very minimal approach. Although perhaps it could say more clearly that the WGs are in charge and that whatever the proposed WG produces is advisory in nature. I do believe however that over time, WGs will adopt useful improvements.

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Apr 2021 08:58:31 +1200

Nico raises a point that has been in my mind: why is this an IETF issue,
since presumably it applies to all RFC streams?

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. There is a
strong case for the latter.

Regards
   Brian Carpenter

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 6 Apr 2021 17:10:02 -0400

While this (terminology) could be handled on a series-wide basis, it 
does not have to be.  The IETF can adopt policies for conent of the IETF 
stream that are more restrictive than the RFC Editor.  While I think 
getting the eventual RFC Series quasi-wg to look at this is worth-while, 
I do not see why that should gate the IETF looking at the quesiton.

Yours,
Joel

---

From: Nico Williams <[email-masked]>
Date: Tue, 6 Apr 2021 16:26:08 -0500

On Tue, Apr 06, 2021 at 05:10:02PM -0400, Joel M. Halpern wrote:
> While this (terminology) could be handled on a series-wide basis, it does
> not have to be.  The IETF can adopt policies for conent of the IETF stream
> that are more restrictive than the RFC Editor.  While I think getting the
> eventual RFC Series quasi-wg to look at this is worth-while, I do not see
> why that should gate the IETF looking at the quesiton.

That's a fine answer to a question Brian did not ask.

It also doesn't address any of John Klensin's points, which I think
really do need to be addressed.

At this point I think the best compromise is for the IESG to indicate
its terminology preferences to the RSE and hope the RSE enforces them
(which, they almost certainly would).  And also maybe the IAB should
publish an RFC on terminology if they like.  And maybe we can have an
RFC asking the RSE to develop a style guide that addresses these issues.
All of those are outcomes I can get behind.

Nico
--

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 6 Apr 2021 17:30:39 -0400

I was, as can be seen below, responding to both you and Brian on the 
issue of whether this is an issue that the IETF can structurally 
address.  It can.  It does not need to wait for the RFC Series policy 
making body to exist and to agree.

On the other hand, regarding your followup comment, for the IESG to 
decide that some terms should be banned without having a community 
process would be a very bad result.  Fortunately, they have not proposed 
to do so.

Yours,
Joel

---

From: Keith Moore <[email-masked]>
Date: Tue, 6 Apr 2021 17:52:13 -0400

+1

---

From: Nico Williams <[email-masked]>
Date: Tue, 6 Apr 2021 17:41:54 -0500

On Tue, Apr 06, 2021 at 05:30:39PM -0400, Joel M. Halpern wrote:
> On the other hand, regarding your followup comment, for the IESG to decide
> that some terms should be banned without having a community process would be
> a very bad result.  Fortunately, they have not proposed to do so.

Indeed, we can agree on this.  However, please see my earlier context
post about this.  We've seen much too heavy-handed an approach by the
IESG, and many serious arguments ignored.  Faking or manufacturing
consensus will do, process-wise, but it is not a good idea.  Perhaps
TERM WG can be an opportunity for a reset, and if it is chartered, I
hope so, though I fear it will be just more of the same.

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 7 Apr 2021 13:38:58 +0100

> On 6 Apr 2021, at 21:58, Brian E Carpenter <[email-masked]> wrote:
> 
>  but I also believe

Exactly my thoughts.

We engineers are good at protocol engineering we should stick to that.

The RFC Editor is good with words and for years have been quietly steering us toward better ways to express our thoughts. Let’s leave them to do that.

As to inclusion and the supporting organisational change, there are professional experts out there that know far more than us, we should contract them to make a study and place recommendations before the IETF community.

Let’s stick to our core competence and get help with the other stuff.

- Stewart

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 7 Apr 2021 22:36:49 +0900

Brian E Carpenter wrote:

> I believe that the charter is good enough as it is,

Even though, it is obvious that the charter is too bad?

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 7 Apr 2021 23:03:29 +0900

Nico Williams wrote:

> hope so

It is obvious that, from the name of the WG, that the WG is hopeless.

"an opportunity for a reset" can only mean to reset IETF entirely, which
is not terminology issues.

						Masataka Ohta

---

From: Leif Johansson <[email-masked]>
Date: Wed, 7 Apr 2021 18:12:13 +0200

Skickat från min iPhone

> 7 apr. 2021 kl. 14:40 skrev Stewart Bryant <[email-masked]>:
> 
> 
> 

+1

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Apr 2021 13:57:38 -0400

>>>>> "Leif" == Leif Johansson <[email-masked]> writes:

    Leif> Skickat från min iPhone

    >>> 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. There is a strong case
    >>> for the latter.
    >>> 
    >>> Regards Brian Carpenter
    >> 
    >> Exactly my thoughts.
    >> 
    >> The RFC Editor is good with words and for years have been quietly
    >> steering us toward better ways to express our thoughts. Let’s
    >> leave them to do that.
    >> 
    >> As to inclusion and the supporting organisational change, there
    >> are professional experts out there that know far more than us, we
    >> should contract them to make a study and place recommendations
    >> before the IETF community.
    >> 

    Leif> +1

In my experience in Debian, things like use of terminology, or debating
how to be inclusive once you have decided on organizational principles
work best in small delegated groups rather than in large consensus
processes.
So, if you have a process (like delegating to the rfc editor) that works
well to resolve issues like this, by all means do so.
It'll save lots of time, frustration and pain.

This is not a criticism of the idea of letting the rfc-editor handle
this, simply a note on some coordination that is required.
For many uses of terminology, adjusting them in the final rfc-editor
stage will be easy and reasonable.
But for some uses of terminology, like the names of entities in a
protocol, and descriptions of their relationships,
the final editing process is too late.
Terms will already be baked into implementations and the minds of
people.

So, even if the rfc editor is going to make recommendations, these
recommendations may need to be consumed earlier than in the final
editing process.

Again, I think that can work fine, but it is something to consider.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 8 Apr 2021 23:20:08 +0200

> Again, I think that can work fine, but it is something to consider.

No doubt.

I think the point is we have existence proof that this can be done.

---

From: John Scudder <[email-masked]>
Date: Fri, 9 Apr 2021 00:57:40 +0000

On Apr 6, 2021, at 5:26 PM, Nico Williams <[email-masked]> wrote:
> (which, they almost certainly would).

“Hope the RSE enforces them”. Enforcement would be a significant step beyond the mere “recommendation” that was in the proposed charter. I’m surprised you’re advocating for this more prescriptive approach. 

—John

---

From: Nico Williams <[email-masked]>
Date: Fri, 9 Apr 2021 11:05:40 -0500

On Fri, Apr 09, 2021 at 12:57:40AM +0000, John Scudder wrote:
> “Hope the RSE enforces them”. Enforcement would be a significant step
> beyond the mere “recommendation” that was in the proposed charter. I’m
> surprised you’re advocating for this more prescriptive approach. 

I wasn't expressing _my_ hope.  I should have been clearer.

My proposal, fleshed out:

 - direct the RSE to develop terminology standards;

 - direct the RPC to enforce the RSE's terminology standards;

 - whenever an author or authors, as well as the responsible AD,
   disagree with editorial changes made or proposed by the RPC, they may
   override the RPC's change,

 - but if the RPC feels strongly about it, they may request a WG LC on
   this issue.

 - There would be no IESG or IETF involvement in resolving any such
   disputes.

Nico
--

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Apr 2021 08:36:59 +1200

Nico,

>  - direct the RSE to develop terminology standards;

We don't yet know the future of the "RSE" role, but what is certain
is that the IETF can't "direct" that person in any plausible model.
 
>  - direct the RPC to enforce the RSE's terminology standards;

Generally speaking the RPC applies the agreed style guide, so
any terminology standards or guidelines would be part of the style
guide. We don't yet know the future of how the style guide is
maintained.

>    override the RPC's change,

That's always been a matter of negotiation. I don't see that changing,
but if it does, it will be an RFC Series policy matter. We don't yet know
the future of how RFC Series policy is set.

>  - but if the RPC feels strongly about it, they may request a WG LC on

That seems very weird. The RPC as an organisation has no standing in
the IETF process.
 
>  - There would be no IESG or IETF involvement in resolving any such

That's self-contradictory. You just suggested a WG LC, i.e. part of the
IETF process. And of course if a draft is changed after IETF LC,
it needs agreement from at least the AD, and possibly a repeat of the
IETF LC and IESG approval.

Regards
    Brian

---

From: Nico Williams <[email-masked]>
Date: Fri, 9 Apr 2021 16:39:08 -0500

> is that the IETF can't "direct" that person in any plausible model.

Tell me more.  I mean, I don't buy this assertion.  I'm quite certain
that the IETF could impose some requirements on publication within the
IETF stream.

> guide. We don't yet know the future of how the style guide is

Right, well, maybe TERM WG needs to provide input to the style guide.
That's essentially what it would be doing as proposed, only without
saying so.  So I don't see the problem with phrasing it in this way
(style guide update) instead.

> the future of how RFC Series policy is set.

See above.

> That seems very weird. The RPC as an organisation has no standing in

They would be applying the style guide.

> IETF LC and IESG approval.

To be more precise, the IESG as a whole would get no say apart from the
responsible AD, and there would be no IETF LC.

We're talking about a s/X/Y/g substitution that would be recommended or
required by the STYLE guide and which may not get applied.  The idea
with eliding IESG approval and IETF LC at this stage is that if this was
controversial, it would have been caught earlier, and to avoid divisive
later controversy like what we're seeing.

Nico
--

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Apr 2021 10:06:39 +1200

> that the IETF could impose some requirements on publication within the

Oh yes, but why wouldn't that happen before the draft goes to the
RFC Editor in the first place?

> (style guide update) instead.

That would be fine, but the proposed future RFC model would
only treat that as input, not as a done deal.

> responsible AD, and there would be no IETF LC.

That would definitely needs an update to RFC2026.

> later controversy like what we're seeing.

It's much better for everybody, I think, if it was caught earlier.
But RFC8962 does not apply.

    Brian

---

From: Nico Williams <[email-masked]>
Date: Fri, 9 Apr 2021 17:25:23 -0500

> RFC Editor in the first place?

Because we're talking about all future RFCs, not one?

> only treat that as input, not as a done deal.

Sure, but in both cases it's the IETF making these changes, so we get
to.  We might have to merge or sequence TERM with, what is it, RFCED?,
but whatever the case, it can be done.

> That would definitely needs an update to RFC2026.

Again, that's doable.

> It's much better for everybody, I think, if it was caught earlier.

Yes.

Nico
--

---

From: John C Klensin <[email-masked]>
Date: Fri, 09 Apr 2021 18:40:15 -0400

--On Saturday, April 10, 2021 08:36 +1200 Brian E Carpenter
<[email-masked]> wrote:

> We don't yet know the future of the "RSE" role, but what is
> certain is that the IETF can't "direct" that person in any
> plausible model.

There are, of course, already terminology standards about, e.g.,
abbreviations.  They are built into the Style Manual whose
status and future are, as you point out below, uncertain.  Nico,
are you really saying "'direct' the RSE to expand the Style
Manual to incorporate this type of terminology guidance"?  I
agree with Brian that doesn't really work (especially in the
short term), but am trying to be sure I understand what you are
suggesting.
   
> any terminology standards or guidelines would be part of the
> style guide. We don't yet know the future of how the style
> guide is maintained.
 
>>  - whenever an author or authors, as well as the responsible
>>  AD, disagree with editorial changes made or proposed by the
>>    RPC, they may override the RPC's change,
> 
> That's always been a matter of negotiation. I don't see that
> changing, but if it does, it will be an RFC Series policy
> matter. We don't yet know the future of how RFC Series policy
> is set.
> 
>>  - but if the RPC feels strongly about it, they may request a
>>  WG LC on this issue.
> 
> That seems very weird. The RPC as an organisation has no
> standing in the IETF process.

I agree about weirdness.  However, the RPC (presumably in
coordination with the RSE) and its predecessors have always, at
least theoretically, had the ability to send a document back to
the IESG (or other stream manager organizations) as unacceptable
for the Series until after specified problems are remedied.  At
the discretion of the IESG, that could result in the document
being sent back to the WG, in trying to negotiate, or in
instructing that the document be published unedited (possibly
with a strong disclaimer from the RFC Editor about the document
emitting a bad smell).  Any of those options are rather drastic;
I'd consider it a failure in the system if a document,
especially an IETF Stream consensus document, that required that
sort of mechanism got that far.

And, as Brian and others have more or less pointed out, there
are no guarantees that all aspects of that model will survive
the current discussions about the RFC Editor Function.

>>  - There would be no IESG or IETF involvement in resolving
>>  any such disputes.
> 
> That's self-contradictory. You just suggested a WG LC, i.e.
> part of the IETF process. And of course if a draft is changed
> after IETF LC, it needs agreement from at least the AD, and
> possibly a repeat of the IETF LC and IESG approval.

Right.  But, borrowing from another discussion, plans like "an
AD can override the RPC in a matter like this" have their own
issues, starting from there being absolutely no guarantee that
any particular AD will have expertise in these matters above and
beyond their personal preferences.  And letting ADs dictate the
content and presentation of documents to suit their personal
preferences contradicts most of what we have been saying about
IETF consensus in the last 25 or 30 years.

I continue to believe that we are risking turning something that
should be a process of educating the community and raising
sensitivities -- goals with which the current proposed charter
seems consistent even though I continue to have doubts about it
being the right way to proceed -- into something rigid and a
source of situations that would lead to disputes and require
dispute resolution processes and probably spawn food fights on
this list.  None of that is good for the IETF --and, if it
occurs with any frequency, is likely to cause people to
self-exclude-- no matter the outcome.   I note that the RFC
Editor [Function] has had the ability to say "this terminology
and phrasing is bad for the Series, please fix it" and has been
charged with creating and preserving editorial consistency in
the Series since early in the 1970s.  Despite changes in
personnel and structure, they have been doing that for that
long.   I hope nothing in the RFC Editor future review changes
that, at least without creating an equally or more effective
alternative.  If there is consensus that these terminology
issues represent a problem worth fixing (the draft charter
claims there is and I see no evidence on which to disagree) and
we can, in some way, reach consensus about what is inappropriate
and how to deal with it, I would expect that to make its way
into the editing process (as long as it makes professional
editorial sense).  If we need to start "directing" anyone to do
anything or to talk about "enforcement" procedures and/or
appeals from them, I think we have more fundamental problems
than this particular WG effort could appropriately address...
regardless of how we tune the WG or even if we replace it with a
different model (as, fwiw, I would prefer).

    john

---

From: John C Klensin <[email-masked]>
Date: Fri, 09 Apr 2021 19:09:40 -0400

--On Saturday, April 10, 2021 10:06 +1200 Brian E Carpenter
<[email-masked]> wrote:

>> We're talking about a s/X/Y/g substitution that would be
>> recommended or required by the STYLE guide and which may not
>> get applied.  The idea with eliding IESG approval and IETF LC
>> at this stage is that if this was controversial, it would
>> have been caught earlier, and to avoid divisive later
>> controversy like what we're seeing.
> 

Ah.  There is another part of the above that is worth commenting
on.  Experience (and my shelf of style manuals contains pieces
on, e.g., non-sexist writing and associated terminology changes
go back to the 1970s --the terms of greatest interest may be
relatively new, but the discussions are not) suggests that many
of the substitutions will not be s/X/Y/g and that some may
require subtle editorial judgments and then enforcement of
consistency.  Two simple examples:  if "we" decide that the
solution for "he" and "she" is "them", then, if the author wrote
"he or she" you would not want to end up with "them or them",
which is what that sort of mechanism substitution would give
you.  In addition, someone needs to decide whether, if "them" is
substituted for "he" as the subject of a sentence, it takes a
plural or singular verb.   I stopped caring about the choice
long ago but it should be made in a way that is consistent, and
consistently applied, across the RFC Series or at least within
individual documents.

On the other hand, if this really were s/X/Y/g, the IESG could
decide to build it into the mandatory part of the nits checker
and avoid the whole "enforcement" discussion.

   john

---

From: "[email-masked]" <[email-masked]>
Date: Sun, 11 Apr 2021 00:27:45 +0000 (UTC)

On Saturday, 10 April 2021, 09:10:24 GMT+10, John C Klensin <[email-masked]> wrote:

[..]
Two simple examples:  if "we" decide that the
[..]

This exact problem is why the 'RFC Editor Considerations' section of the 'modest proposal' draft:

https://datatracker.ietf.org/doc/draft-wood-term-modest-proposal/?include_text=1

calls out 'themself'.

L.

is speaking, of course, for themself.

Lloyd Wood

[email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Tue, 13 Apr 2021 19:44:05 +0300

Brian,

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

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#section-1.2 <https://tools.ietf.org/html/draft-ietf-tls-rfc8446bis-00#section-1.2> 

All this leads me to believe that the WGs are and should be in charge of the bigger modifications. This still leaves room for:

- a new terminology working group to provide guidance & principles
- RFC editor to check and adjust text (and possibly highlight issues back to the authors)*

Brian, what was your thought regarding the division of work and who would do what? And in your mind, what level of decisions would be required for actions similar the examples above?

Jari

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

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Apr 2021 16:54:43 +0000

I believe it is important for the IETF to say something that has the force of IETF consensus behind it.  Instructions to the RFC Editor have not, and I would be against doing so in this case because the lack of consensus makes the editorial changes less well-justified.

If the consensus is that we should not do this, I would be highly disappointed, but I would accept it as a consensus decision.

---

From: "John Levine" <[email-masked]>
Date: 13 Apr 2021 16:01:27 -0400

It appears that Salz, Rich <[email-masked]> said:
>-=-=-=-=-=-
>I believe it is important for the IETF to say something that has the force of IETF consensus behind it.  Instructions to the RFC Editor have not, and I would
>be against doing so in this case because the lack of consensus makes the editorial changes less well-justified.
>

Language policing is not part of the RFC Editor's job.  If the IETF wants to set language standards, that is fine,
but it is up to the IETF itself to follow and if need be enforce those standards, not anyone else.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Apr 2021 09:19:58 +1200

Hi Jari,

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

Yes, certainly.

> 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#section-1.2 
> 
> All this leads me to believe that the WGs are and should be in charge of the bigger modifications. 

Completely agreed. But my concern is that the RFC Series as a whole would look pretty stupid if (to take a strawman example) the IETF "enforced" 'blocklist' and the IRTF "enforced" 'denylist' and some other stream decided that 'blacklist' is just fine.

So while I am not actively opposed to starting the TERM WG, I am concerned about how we will proceed later on at the level of the RFC series as a whole.

> This still leaves room for:
> 

What you describe is fine as far as the IETF stream goes.

Regards
    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Apr 2021 09:53:07 +1200

On 14-Apr-21 08:01, John Levine wrote:
> Language policing is not part of the RFC Editor's job.

That may be true today, but when we have a new regime for the RFC Series model it might change, or at least, this whole issue might become part of the style guide.

> If the IETF wants to set language standards, that is fine,

s/standards/guidelines/ 

> but it is up to the IETF itself to follow and if need be enforce those standards, not anyone else.

I hope you would apply that statement to all RFC streams, not just the IETF stream.

Regards
    Brian

---

From: Keith Moore <[email-masked]>
Date: Tue, 13 Apr 2021 19:35:02 -0400

> That may be true today, but when we have a new regime for the RFC Series model it might change, or at least, this whole issue might become part of the style guide.

The style guide seems like a reasonable place for such advice (not 
policing) to be, and maintaining the style guide seems like the RFC 
Editor's job.

I would further recommend that the RFC Editor ask specific areas within 
IETF to make their consensus-based preferences for area-specific 
language known, e.g. the difference between on-path attack and in-path 
attack.   But I would like to have the RFC Editor be the 
compiler/maintainer of such information.

Keith

---

From: John C Klensin <[email-masked]>
Date: Tue, 13 Apr 2021 21:30:09 -0400

--On Wednesday, April 14, 2021 09:53 +1200 Brian E Carpenter
<[email-masked]> wrote:

>>> If the consensus is that we should not do this, I would be
>>> highly disappointed, but I would accept it as a consensus
>>> decision.
>> 
> That may be true today, but when we have a new regime for the
> RFC Series model it might change, or at least, this whole
> issue might become part of the style guide.

Actually, Brian, putting "language policing" aside and instead
discussing control of the vocabulary used in RFCs, that has
always been part of the RFC Editor's job.  If we were now going
to say "the RFC Editor is responsible for choices about
technical terminology consistent with the rest of the Series,
for the difference between British and American English, for
consistency of decisions about sentence structure and
punctuation choices, etc., but not for any words the TERM WG
might choose to put on its list... well, we could do that but I
fear it could lead us into a silly state, especially if, as your
other note suggested, the vocabularies were not coordinated
across the Series.

For that reason, I see it as much more plausible if any of this
becomes advice to the community (for sorting out terminology and
vocabulary before things go over the wall to the RFC Editor) but
leaving finsl text in the hands of the RFC Editor Function...
and ultimately getting whatever guidance is adopted into the
style manual seems just right.

   john

---

From: tom petch <[email-masked]>
Date: Wed, 14 Apr 2021 12:38:59 +0100

Jari

At a tangent to the discussion on the role of the RFC Editor, I note 
that the style guide references TERMS, which is  a Terms List for people 
to use, e.g IPsec and not IPSec.

Calling a WG TERM but having it look at what is for me a very different 
aspect to terminology, inclusiveness, seems to me to be a good source of 
confusion in times to come.

Tom Petch

---

From: Nico Williams <[email-masked]>
Date: Wed, 14 Apr 2021 10:57:44 -0500

On Wed, Apr 14, 2021 at 09:19:58AM +1200, Brian E Carpenter wrote:
> Completely agreed. But my concern is that the RFC Series as a whole
> would look pretty stupid if (to take a strawman example) the IETF
                                         ^^^^^^^^

My daughter's future mother-in-law told me that some other lady she was
talking to recently objected to the word 'strawman', much like some here
object to MITM.  Off with your head, Brian!

---

From: John C Klensin <[email-masked]>
Date: Sat, 17 Apr 2021 17:35:29 -0400

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
<[email-masked]> 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].

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

> - a new terminology working group to provide guidance &

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.

---

From: John C Klensin <[email-masked]>
Date: Sat, 17 Apr 2021 21:19:12 -0400

--On Wednesday, April 14, 2021 10:57 -0500 Nico Williams
<[email-masked]> wrote:

>> Completely agreed. But my concern is that the RFC Series as a
>> whole would look pretty stupid if (to take a strawman
>> example) the IETF
>                                          ^^^^^^^^
> 
> My daughter's future mother-in-law told me that some other
> lady she was talking to recently objected to the word
> 'strawman', much like some here object to MITM.  Off with your
> head, Brian!

Out of curiosity, would she prefer "strawperson", "strawentity",
"Aunt Sally"?  or how about "paper tiger", which doesn't mean
the same thing but might be close in some contexts.. and not
only is "tiger" not gender specific but I've never heard of
tigers taking specific offense about the names they are called
(although I somehow doubt that those tigers who speak human
languages would call themselves "tiger" so they might be
offended on that basis).

    john

---

From: Lloyd W <[email-masked]>
Date: Sun, 18 Apr 2021 11:37:55 +1000

any tiger prefers the fearful symmetry of "I".

Lloyd Wood
[email-masked]

a poem, by William Blake.

> On 18 Apr 2021, at 11:20, John C Klensin <[email-masked]> wrote:
> 
> and not