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

"Paul Hoffman" <> Wed, 12 September 2018 21:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CDFB130EA9 for <>; Wed, 12 Sep 2018 14:36:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tAn6QXkeImmJ for <>; Wed, 12 Sep 2018 14:36:28 -0700 (PDT)
Received: from (Opus1.Proper.COM []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DADF130DFA for <>; Wed, 12 Sep 2018 14:36:28 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id w8CLZsCY030502 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Sep 2018 14:35:55 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: "Paul Hoffman" <>
To: "Adam Roach" <>
Cc: IETF <>
Subject: Re: Proposed IESG Statement on the use of the =?utf-8?b?4oCcVXBkYXRlc+KAnQ==?= header
Date: Wed, 12 Sep 2018 14:36:25 -0700
X-Mailer: MailMate (1.12r5523)
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
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:36:30 -0000

On 12 Sep 2018, at 14:18, 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?

To tell the reader if they want to read the Introduction. For example, 
it should indicate whether this is a description of the new Foo 
protocol, or an update to the Foo protocol, or just the definition of an 
extension. If it is defining a new protocol, what general realm is that 
protocol in?

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

Yes, this is a bad idea, but there are needs of the reader that short 
abstracts fill just fine.

--Paul Hoffman