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

Adam Roach <adam@nostrum.com> Wed, 12 September 2018 21:18 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF8B130DC5 for <ietf@ietfa.amsl.com>; Wed, 12 Sep 2018 14:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzfEzqpmH0w7 for <ietf@ietfa.amsl.com>; Wed, 12 Sep 2018 14:18:39 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED7821200D7 for <ietf@ietf.org>; Wed, 12 Sep 2018 14:18:38 -0700 (PDT)
Received: from Svantevit.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (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 adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.roach.at
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 <stephen.farrell@cs.tcd.ie>
Cc: IETF <ietf@ietf.org>
References: <59F6DED7-8D39-4206-8268-22AB6A99A876@nostrum.com> <3BAD273A-C92B-4B81-AECB-253D212ECF22@gmail.com> <a082b73c-77df-5277-adea-5e13f7b52871@nostrum.com> <9fab7fbf-151a-fe06-b1ca-c31367113805@cs.tcd.ie>
From: Adam Roach <adam@nostrum.com>
Message-ID: <3d96a4b2-1c4c-630d-14e0-c83810031e71@nostrum.com>
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: <9fab7fbf-151a-fe06-b1ca-c31367113805@cs.tcd.ie>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/NopCWvJPYOb04wIO0Z_WAfmvDz0>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=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].

/a

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