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

"Paul Hoffman" <paul.hoffman@vpnc.org> Wed, 12 September 2018 14:45 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 EF620130E06; Wed, 12 Sep 2018 07:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 npfH5NXKaUjO; Wed, 12 Sep 2018 07:45:35 -0700 (PDT)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53BF5128CB7; Wed, 12 Sep 2018 07:45:35 -0700 (PDT)
Received: from [10.32.60.117] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w8CEj00F005547 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 Sep 2018 07:45:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.117]
From: "Paul Hoffman" <paul.hoffman@vpnc.org>
To: ietf@ietf.org, "The IESG" <iesg@ietf.org>
Subject: Re: Proposed IESG Statement on the use of the =?utf-8?b?4oCcVXBkYXRlc+KAnQ==?= header
Date: Wed, 12 Sep 2018 07:45:31 -0700
X-Mailer: MailMate (1.12r5523)
Message-ID: <AFE1600A-7883-4CD6-BD6A-232E12514123@vpnc.org>
In-Reply-To: <8DA3AA49-BB06-4DA6-A028-F487FC9822EB@sn3rd.com>
References: <59F6DED7-8D39-4206-8268-22AB6A99A876@nostrum.com> <8DA3AA49-BB06-4DA6-A028-F487FC9822EB@sn3rd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/u8HuRotSiFxlsMO2dRjoayll80Q>
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 14:45:37 -0000

On 12 Sep 2018, at 7:33, Sean Turner wrote:

>> The specific reasons that a given RFC updates another should be 
>> described in the abstract and body of the new RFC. The level of 
>> detail may differ between the abstract and the body; typically an 
>> abstract should contain enough detail to help readers decide if they 
>> need to read the rest of the RFC. The body should contain enough 
>> detail for readers to fully understand the nature of the update.
>
> I like to say that I hate the whole list the reasons why in the 
> abstract.  I understand that we also say what RFCs are updated in the 
> abstract because there are some tools that don’t display the 
> meta-data and that we do it so readers will know whether or not to 
> keep reading.  That’s great for an RFC that’s updating one RFC and 
> it keeps in line with keep the abstract succinct plus the boiler plate 
> on the 1st page.  But, when you’ve got an RFC that’s going to 
> update say eight (8) RFCs that this is kinda crazy.

Sean's exactly right here. Having to add a lot of new text to the 
abstract basically makes it a mini-introduction. Instead, please 
consider:

The specific reasons that a given RFC updates another should be 
described near the top of the Introduction section of the new RFC, 
possibly in its own sub-section. This text should contain enough detail 
to help readers who are familiar with the specification that is being 
updated to decide if they need to read the rest of this newer RFC. This 
text must contain enough detail for readers to fully understand the 
nature of the update.

--Paul Hoffman