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

Sam Hartman <> Wed, 07 April 2021 17:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CC6853A2303 for <>; Wed, 7 Apr 2021 10:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mWLDgN2lewk8 for <>; Wed, 7 Apr 2021 10:57:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 795A13A22FF for <>; Wed, 7 Apr 2021 10:57:40 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC95D303F9; Wed, 7 Apr 2021 13:57:39 -0400 (EDT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KWm5-aZy3Exy; Wed, 7 Apr 2021 13:57:39 -0400 (EDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) (Authenticated sender: hartmans-laptop) by (Postfix) with ESMTPSA; Wed, 7 Apr 2021 13:57:39 -0400 (EDT)
Received: by (Postfix, from userid 8042) id 336F5C9A3F; Wed, 7 Apr 2021 13:57:38 -0400 (EDT)
From: Sam Hartman <>
To: Leif Johansson <>
Cc: Stewart Bryant <>,
Subject: Re: WG Review: Effective Terminology in IETF Documents (term)
References: <> <>
Date: Wed, 07 Apr 2021 13:57:38 -0400
In-Reply-To: <> (Leif Johansson's message of "Wed, 7 Apr 2021 18:12:13 +0200")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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: Wed, 07 Apr 2021 17:57:45 -0000

>>>>> "Leif" == Leif Johansson <> writes:

    Leif> Skickat från min iPhone

    >> 7 apr. 2021 kl. 14:40 skrev Stewart Bryant
    >> <>om>:
    >>> On 6 Apr 2021, at 21:58, Brian E Carpenter
    >>> <> wrote:
    >>> 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.
    >> 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

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

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.