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

Jari Arkko <> Tue, 13 April 2021 16:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 848A73A1E6B for <>; Tue, 13 Apr 2021 09:46:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.102
X-Spam-Status: No, score=-1.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CsV0xT8kU5Xq for <>; Tue, 13 Apr 2021 09:46:53 -0700 (PDT)
Received: from (unknown [IPv6:2001:14b8:1829::130]) by (Postfix) with ESMTP id 8A75F3A1E5B for <>; Tue, 13 Apr 2021 09:44:12 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD9EC6601E7; Tue, 13 Apr 2021 19:44:09 +0300 (EEST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fkENbktlUtO3; Tue, 13 Apr 2021 19:44:06 +0300 (EEST)
Received: from [] ( []) by (Postfix) with ESMTPS id B0B3666012D; Tue, 13 Apr 2021 19:44:06 +0300 (EEST)
From: Jari Arkko <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_63A6DA6A-DD8F-4564-8289-AE8576055CCE"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: Re: WG Review: Effective Terminology in IETF Documents (term)
Date: Tue, 13 Apr 2021 19:44:05 +0300
In-Reply-To: <>
Cc: IETF <>
To: Brian E Carpenter <>
References: <> <> <> <D18D87D95723A68D8E75B6BC@PSB> <20210406152930.GR3828@localhost> <>
X-Mailer: Apple Mail (2.3273)
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Apr 2021 16:46:58 -0000


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

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

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?


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