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

Brian E Carpenter <> Tue, 13 April 2021 21:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74EC03A0E83 for <>; Tue, 13 Apr 2021 14:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aXM3G8w2jCLN for <>; Tue, 13 Apr 2021 14:20:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EEEC43A0E81 for <>; Tue, 13 Apr 2021 14:20:03 -0700 (PDT)
Received: by with SMTP id f29so12868778pgm.8 for <>; Tue, 13 Apr 2021 14:20:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=8zVhvhWUt2SCyXPLUYa20oUCPY/z2b+A5V9utbkRY1Q=; b=pTFFDVkD53Fb3QWh9k9KNBg7t1YrXC0Vvc7mlgPVNS/NiN35vLawl3/0PBav9rJZqO ephSd9CHwKtWsZT3ov+w0k3fOHPEZvw6MsdvEVRoEmyV8wHz8WPEIX2s5JvFDNKUZuTN J50ZRvp3BgO3H5cyFpdpYtrVGQbSP4lWgtZcHDoOcUYAUV0CVEU+wrX0MSSXqIUtoyeO PQ68yKY5a9IC0YQAxZQ9s2xzseEXcH7/tR/gHPmA59sXYxcug3MJXQhlD0vIrkafNpox 32Y8HQAzxKDS1JSJGUOSdN9vi5EHY0sZsimhGWLtoHhBLGJAYc6x5QOEIFSuuVjy0tG+ +2fA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=8zVhvhWUt2SCyXPLUYa20oUCPY/z2b+A5V9utbkRY1Q=; b=CcHcBpoXJUdX9jC7cljuj3RHlkS1MfVXGFdt/LTDYI24+E9sxTdcf6rE/tXT2bOVJz 0An63PgziawR7rZ05RUkc0NjSCuaN3IyrhBR3L7Xd6N9M3EcSeldLEYbq8wibFLV/bqN 8yYv8KMLMYSwIfPASPAkAu1AongpmySn4gddSINuQFPLSdtRovxFxy8yoCUDFI3HQQqH jlTfDBvEOqWVxCvFDgsGiH6j69JCUaPUbO078pjMHuKQIifHel3ZzB6u0+qLGobQgEne yThuD0bPZpXCo6DXb80vQPIKSB1O4bLe/P/CyjG6C1zYHH/7F4lZSq839noBayaZOvNP 0xPg==
X-Gm-Message-State: AOAM532N2kcJ3/U8bWfFLG5n2WMI0dUv7wlDQk91EDnUIpopKfafiQSv GOgcoJaXLDMuHVDV4cizZfkSCaY+3ReE7A==
X-Google-Smtp-Source: ABdhPJwxqD+tl6iEp7SlDASPbL4+QkkP9nN6GBBCi5U3p4njXAzPfJCnTStA934frOVU0FZDUKedEg==
X-Received: by 2002:a63:d009:: with SMTP id z9mr33857546pgf.16.1618348802706; Tue, 13 Apr 2021 14:20:02 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id 9sm1430984pfj.187.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Apr 2021 14:20:02 -0700 (PDT)
Subject: Re: WG Review: Effective Terminology in IETF Documents (term)
To: Jari Arkko <>
Cc: IETF <>
References: <> <> <> <D18D87D95723A68D8E75B6BC@PSB> <20210406152930.GR3828@localhost> <> <>
From: Brian E Carpenter <>
Message-ID: <>
Date: Wed, 14 Apr 2021 09:19:58 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
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: Tue, 13 Apr 2021 21:20:05 -0000

Hi Jari,

On 14-Apr-21 04:44, Jari Arkko 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…)

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

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

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