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

Brian E Carpenter <> Fri, 09 April 2021 20:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2CF3C3A0FCB for <>; Fri, 9 Apr 2021 13:37:08 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 hLWV6awXOjUS for <>; Fri, 9 Apr 2021 13:37:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B96713A0FBB for <>; Fri, 9 Apr 2021 13:37:03 -0700 (PDT)
Received: by with SMTP id p10so3339040pld.0 for <>; Fri, 09 Apr 2021 13:37: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=unuLbCltyuEeEWHqIPniC3WmGcOeQ/cZFqXnj/+heKo=; b=dt+9ccLuqoR3pbXFV38PS066fad0p7gAv19UrCPEay0WPst9noYUIf0hExjzzDsRG+ SApRNFSGOUN9iwiTXp9kKAB6tsmm3Nq6hOthgqxd/xaR/lFaym1Z8cLFEBZRVCdwIl/I +d0bIC6sTa0Yfzz7MPVnY07m5ohy1ISs5AZOuGB/9KBkxjRqxj+pv+OJ3oZuD1OeQ5NW Zwg07dWXvQRHXQpQLsVbkIWVxcgOp7OkAENwWONehAXjfKYD9QJR4GZ5Ri+C+xOBOU5B 2v9xAJFT1oAU/N3ov3ReXIQcPhpWoWUmccQUcUhGwLfZwtJR3DZ2gnGkllO/XI0fVv0o 5lsA==
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=unuLbCltyuEeEWHqIPniC3WmGcOeQ/cZFqXnj/+heKo=; b=tDrz310rwphvuLpZr97ZGD+oFeFA84fa7U7PiH2oFRzMb7hSImwuW8yVDQha9SY4IS MxzqtQLMCjzRaaLFTZThYI+WiHv8ubSttrbFLoaHbTNPTJ3xG/B0BKjZIy/UUStsxPVZ ash4F9hAZDIgDfiLue+3YQ6AW/NQTerNVILQPSyQcXmuz7Z/XAAt84ChPsLy9nMDCCdg T6HkGA0S3gDVtB3RyBA1RaW1uVKX202yO3YvG4PBfoWEL3qikrEFX4FLAjglLONQs4qU TDVXzo2LpEOGuR2kNOixcWHAve2Miv0boTOy084LeMv9jgx/lezTbkBBLvMDD2/p1n6S btOQ==
X-Gm-Message-State: AOAM533dWnC2eNk7srU8LJ6kUMDXqBTGjgtKW5pc+m2/J7RFAVwrEt1A oUwKMSjcbjTqzfFJMN7ZjKA/exmbjIUA/g==
X-Google-Smtp-Source: ABdhPJzV5/edSbhVdusYJstU2gdZ+Qjup+8cQiYqWZsjd+X92w881WZfk50vo6RyBshIoDuW0Uy05w==
X-Received: by 2002:a17:90a:4a8e:: with SMTP id f14mr15632271pjh.84.1618000622294; Fri, 09 Apr 2021 13:37:02 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id a26sm3076034pff.149.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Apr 2021 13:37:01 -0700 (PDT)
Subject: Re: WG Review: Effective Terminology in IETF Documents (term)
To: Nico Williams <>, John Scudder <>
Cc: "" <>
References: <> <> <> <D18D87D95723A68D8E75B6BC@PSB> <20210406152930.GR3828@localhost> <> <> <20210406212509.GS3828@localhost> <> <20210409160539.GA9612@localhost>
From: Brian E Carpenter <>
Message-ID: <>
Date: Sat, 10 Apr 2021 08:36:59 +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: <20210409160539.GA9612@localhost>
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: Fri, 09 Apr 2021 20:37:08 -0000


On 10-Apr-21 04:05, Nico Williams wrote:
> On Fri, Apr 09, 2021 at 12:57:40AM +0000, John Scudder wrote:
>> On Apr 6, 2021, at 5:26 PM, Nico Williams <> wrote:
>>> 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).
>> “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;

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

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