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

Adam Roach <> Wed, 12 September 2018 18:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 94F69130E5E; Wed, 12 Sep 2018 11:10:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XValA_ZLFS92; Wed, 12 Sep 2018 11:10:26 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 01798126CB6; Wed, 12 Sep 2018 11:10:25 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id w8CIANUb093637 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 12 Sep 2018 13:10:24 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be
Subject: =?UTF-8?Q?Re=3a_Proposed_IESG_Statement_on_the_use_of_the_=e2=80=9c?= =?UTF-8?Q?Updates=e2=80=9d_header?=
To: Bob Hinden <>, Ben Campbell <>
Cc: IETF <>, IESG <>
References: <> <>
From: Adam Roach <>
Message-ID: <>
Date: Wed, 12 Sep 2018 13:10:18 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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 18:10:28 -0000

Thanks for weighing in, Bob. I have a request for clarification.

On 9/11/18 1:31 PM, Bob Hinden wrote:
> I worry about the
>     "abstract should contain enough detail to help readers decide if they need to read the rest of the RFC”
> This may result in a long Abstract depending on the nature of the “update” and defeat the purpose of the abstract if it gets too long.

Based on other people's comments, you're not alone in such a concern, 
and I'd like help understanding why. My conception of document abstracts 
in general is that they serve the singular purpose of letting people 
know whether they should read the rest of the document. This makes the 
text you quote almost tautological.

Clearly, you (and others) have a different notion of the purpose of the 
abstract section, and that understanding is driving these concerns. I 
don't think we can reach a reasonable consensus unless we surface what 
those differences in understanding are.

Can you concisely describe what purpose you believe an abstract serves?