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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6EF8B130DC5 for <>; Wed, 12 Sep 2018 14:18:40 -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 qzfEzqpmH0w7 for <>; Wed, 12 Sep 2018 14:18:39 -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 ED7821200D7 for <>; Wed, 12 Sep 2018 14:18:38 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id w8CLIXu4024393 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 12 Sep 2018 16:18:34 -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: Stephen Farrell <>
Cc: IETF <>
References: <> <> <> <>
From: Adam Roach <>
Message-ID: <>
Date: Wed, 12 Sep 2018 16:18:28 -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 21:18:41 -0000

On 9/12/18 3:51 PM, Stephen Farrell wrote:
> Hiya,
> On 12/09/18 19:10, Adam Roach wrote:
>> 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?
> There are more than just functional properties. There's the issue of
> folks having to jump through bureaucratic hoops. For some documents,
> it'll be just fine if this information is somewhere other than the
> abstract.

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


[1] To be clear, I think this would be a Really Bad Idea, but it's the 
only logical conclusion I can draw from push-back on a proposal that our 
abstracts do the one thing that abstracts are intended to do.