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

Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 12 September 2018 22:07 UTC

Return-Path: <brian.e.carpenter@gmail.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 AD82F130ED4 for <ietf@ietfa.amsl.com>; Wed, 12 Sep 2018 15:07:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 iOYOeKoDBl6U for <ietf@ietfa.amsl.com>; Wed, 12 Sep 2018 15:07:53 -0700 (PDT)
Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) (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 6EB78130ED2 for <ietf@ietf.org>; Wed, 12 Sep 2018 15:07:53 -0700 (PDT)
Received: by mail-pf1-x42f.google.com with SMTP id k21-v6so1659036pff.11 for <ietf@ietf.org>; Wed, 12 Sep 2018 15:07:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tWajIrEguq51EsS25yUXbQZkbKCXrDCM3vf/q856CDM=; b=R8k104BiDRyF9/hGY8AVKp7TZG+SefVlZtrqUqLOmq0u7x7QUTYSh0X1nO2skrLvw8 ASSPd4ztlOaTBvPJUGJdPj7M2Onyxleg+bjCmUCq7/D6qvb8eMJqNDjOC3fEDlJptlqb fmhnY6SXuPfiCiRe5xuyC/MbSyy7oiBbDkIO536d6BCd5fuUTR8H/O7dKmoxMcoKEGg2 sMXRBi8QxW/b086ZhCN46J73y+pjAMcj/cFAhVyauvUs87pd4294z1QjKWz+sAuxvB2S 2kime2yUWcmQkhGRJbJZV9d5gwM6g81q6Grq4Mrp0PYhlRun2gvsW3wTLugSyXSu1QH7 FB9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tWajIrEguq51EsS25yUXbQZkbKCXrDCM3vf/q856CDM=; b=gkCZYZ1pELNqW1O4QMKG9UWnlDp9oFXyY+eLUa8Kn9Tj6qx+FbEVE9Sxdc8dZfZMq8 n92sa3NecCwhySbg3WKnsBJm5UQzVY3NFHidOfEsIwHIaL6bydUjC/xDq8cxa0ZxOHMO UApoWdz+VdR2sgvuVili0ySWq97RjTZ9EhTYsfYnubqlCtZ4eZZf5IueHqMMdtGxLxQZ lqZ3dYw1giiP53zOQ1YVnd4C7LWT1XADzIvVLJbkZxluuPT5P7/1kKVh8wqvhunNSk1G rOA9i8UCvfxGWuKy+6d3yzOhdSRF4/+1DxQL+LdKYQyAS3ihtN7gP136YEbZUJ1D2O+1 DPGw==
X-Gm-Message-State: APzg51DLerI31CzhOEJo0qPj0o8Rf9VzMx3+E0UR6T7EDguj1yEGe3d9 yQPY4TzwQDMSrhn/U0fNkfUStmBg
X-Google-Smtp-Source: ANB0VdZQ4qTT2WifmmsJdMNlogUO3ufoCranOQHlsq2Wwq0vhRkBoNXFZouIoktGR+YhXLoo8UYnIg==
X-Received: by 2002:a62:cc41:: with SMTP id a62-v6mr4410975pfg.131.1536790072643; Wed, 12 Sep 2018 15:07:52 -0700 (PDT)
Received: from [192.168.178.27] ([118.148.76.40]) by smtp.gmail.com with ESMTPSA id h12-v6sm2616504pfo.135.2018.09.12.15.07.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Sep 2018 15:07:51 -0700 (PDT)
Subject: =?UTF-8?Q?Re:_Proposed_IESG_Statement_on_the_use_of_the_=e2=80=9cUp?= =?UTF-8?B?ZGF0ZXPigJ0gaGVhZGVy?=
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Adam Roach <adam@nostrum.com>
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: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <99cb09cd-6a19-8ab7-e84a-237003d8467b@gmail.com>
Date: Thu, 13 Sep 2018 10:07:46 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <9fab7fbf-151a-fe06-b1ca-c31367113805@cs.tcd.ie>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/r_Nuuv-L0d5AWPi3kbbxhMDBSe4>
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 22:07:55 -0000

On 2018-09-13 08:51, 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.

Exactly. Common sense should apply in all cases. If the abstract is
too long or looks like a catalogue of boring stuff, it will itself
become TL;DR and therefore defeat its own purpose. So all - that's
*all* - of these guidelines should be *guidelines* that are varied
when that seems appropriate. If a document updates 8 others, then
the abstract could say: This document updates all the RFCs underlying
Foobar. Or for a current topic, perhaps: This document updates numerous
RFCs that mention the IAOC.

As Spencer says from time to time, do the right thing. When the rules
or guidelines are wrong, do the right thing.

(Possible update to RFC2119: if MUST is clearly nonsense in a particular
case, ignore it, especially in a BCP.)

   Brian