Re: Proposed IESG Statement on the use of the “Updates” header

Ted Lemon <> Wed, 12 September 2018 21:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 132EC130F46 for <>; Wed, 12 Sep 2018 14:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] 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 ayWKusI5ZWJj for <>; Wed, 12 Sep 2018 14:23:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 508DF130F1A for <>; Wed, 12 Sep 2018 14:23:39 -0700 (PDT)
Received: by with SMTP id k21-v6so1611982pff.11 for <>; Wed, 12 Sep 2018 14:23:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=QPclP0eGa6y0KVnVruxv1RUxcLO2vCsPXmf+XcDIWUs=; b=1CdpR7K1rgJsrqdk/ZZUJh86wUsbA5is/Zzx2Ps2uZ26PGqpCX48+f7ql0dso6OiGj iKupfFiwRpKi2IWI9cUVFxtaPC38kYh4Sq4cvhaS9AV+Kkftm95MVPjXUobi7ZBlJT31 oN+8jP2jInzdm/s03DoR6mtajtu1M+4i3cbtFKfmC7L0WLuV+1ydpG0/+lW95dsUWL3t 1lS0EmeNbRBhH6KwB7xDYMbNtksbo4N+Q1nle5WuQJdQz1buh2V0ZcXGaD7iRv2/EEei lwYN7vPsi74+5wup61LsVZYnsb+0Rn7ouH507IwCae9qWufTlAKxGQMtQUOUuCMLCBZp M+nA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=QPclP0eGa6y0KVnVruxv1RUxcLO2vCsPXmf+XcDIWUs=; b=fkU8olMDXOB3hR2v6fmTPCiqio9ES93bhpOWazW1zxVfVb1d43IVbjAyLmFkv/z8fb JwHbMaX2TmgeLhrWtk07MEdm/+EKbrLKjxcO0AsEbrdQmUPUNm9LClKlM+VonMR+wXhX K35MCul9yBJOp/kI51kJRfkkYdF0SafhK7q1NtOpuW69sUr6243m0zUZAWN/dp0AboV0 /Pq6ZDODLChhhCAB5+sKCL+Wt16oAVoajhuRCZpGkPxFzjEiN9wBu0/NmacJMD+xQKMo kne4WMH7D3iBkwrbGnYOg/0BJ8nENTeRB0sfRa9JVesQZOaQOhKgCh5GrC4hdRzQCL3m mTGw==
X-Gm-Message-State: APzg51Ctic9XP6gdPAIwgvikk+kbZkYFFMl5B1jM6k2LBMN8rb+8vfSe vX1d7HdfxS2K8TpnQVcXgDJz14cmQOI=
X-Google-Smtp-Source: ANB0VdYwDfVhUh+qEZav7PiI6413mFA91L32LuYeOm4HOTYDtsktKOyPFN8Rolyu5PqhiHbzFpMCrw==
X-Received: by 2002:a63:e914:: with SMTP id i20-v6mr4194782pgh.10.1536787418788; Wed, 12 Sep 2018 14:23:38 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id k26-v6sm3798292pfb.167.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Sep 2018 14:23:38 -0700 (PDT)
From: Ted Lemon <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D87D9E21-BE75-4076-88E3-C93B6801ECDC"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Subject: =?utf-8?Q?Re=3A_Proposed_IESG_Statement_on_the_use_of_the_?= =?utf-8?Q?=E2=80=9CUpdates=E2=80=9D_header?=
Date: Wed, 12 Sep 2018 14:23:36 -0700
In-Reply-To: <>
Cc: Stephen Farrell <>, IETF <>
To: Adam Roach <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.100.39)
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, 12 Sep 2018 21:23:49 -0000

On Sep 12, 2018, at 2:18 PM, Adam Roach <> wrote:
> I still don't follow. If the abstract does not contain enough information to let someone know whether they want to read the rest of the RFC, then what purpose *does* it serve? I note that many (non-IETF) protocol specifications are published without an abstract at all. If ours doesn't serve any purpose, then perhaps it's time we discussed whether RFCs need them at all [1].

Abstracts are useful in precisely the way you suggest; the question is whether the abstract has to enumerate what the document updates.

This may not be necessary if the reader would be reading the document anyway because of the contents of the document.   So whether the abstract has to say specifically what is update is a judgment call.   Personally, I prefer to keep abstracts as short as possible—they should definitely say enough that I can decide whether I need to read them, but if they say more than that, then reading the abstract becomes enough work that it might as well just be an introduction (and indeed we often see IETF documents where the abstract and the introduction are largely the same text).