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

Heather Flanagan <> Thu, 13 September 2018 00:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9F32130EE3 for <>; Wed, 12 Sep 2018 17:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4rPXvbuU6HHh for <>; Wed, 12 Sep 2018 17:47:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 11FD8130ED7 for <>; Wed, 12 Sep 2018 17:47:34 -0700 (PDT)
Received: by with SMTP id d19-v6so1899718pgv.1 for <>; Wed, 12 Sep 2018 17:47:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=vRU0WqZkf2a4weNSf3CZVb4/Y0rVtU//ctjpjEpJO0g=; b=cpLbnnJQIUER377uWKgzD/tVSVZ1SQI7neKeNnq2EAXna67tJnZVC6z7wD8M3Dqumk 34DGBTrfxgWIhPhKOViCglGN9haqQDrXg2JyHr99VBEAlc42mkzZycHOmWBiZW0CNikg 2F/qSu4wwSgwG8QnnV1x2G48i1Den0ExR3G0Vvq87O25CmWeRIZbpSLBhyUmJLIPuoV8 WJN9J3uBmDjZs10e6gFMHh9QxIRiLVF7aQXUuAlVZRV6VK7pB1wZrLS89QToBhQ2YlEk 2aiGAmdHXY1186OhMwSggxJ+o0B6oR1Cp+3FxV0EZ9JNcufG64C8ViDFjYdStbLC4fqK XC0w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=vRU0WqZkf2a4weNSf3CZVb4/Y0rVtU//ctjpjEpJO0g=; b=BwJhh1sPpu3JMPyqNRRRDdZULlTC4jAmcViMZmm8ukz3saQhlPvnN85/8gHGnkYziK nqq6Mw7KXA01ZDjJJJdEesDpivmogOX0x/ysfUnDLd7LMVPKH1QmfxRQRJhPs5S7glv1 n+VNDRZ4YUvzEqVgRcqwNIZkTB/zKoLyjr5QrXFjVG+UVJViOeGapUJZFtQ+KkHaJ3CN K0IACc06M7LPO5PfZc2EFgOeOTKVJReHPsQeS3h1XZs96p4hYiCdl1YlKH3DD8dF0Rbj 3c3wCO+P4fXWnTq3lKbIHV6CxXtN9aalznohGth5hh/3myXkkqxuCYJjXvZHKIZe6WF3 FHRA==
X-Gm-Message-State: APzg51BXeVBluVOevonLyB+LWYl6leUPy6dguHQ9i0V26Tf0jYB+nwx/ iQVKzwaqdEjhQyCxDpKxrbHHUzOg
X-Google-Smtp-Source: ANB0VdZaolXltOJjiVXvcZjNK1pwKc3JL/xRRv6CrC/w5k5pwer30z4kUO6/+p5hLqflG0PXoWJgBQ==
X-Received: by 2002:a62:d44a:: with SMTP id u10-v6mr4910990pfl.144.1536799652674; Wed, 12 Sep 2018 17:47:32 -0700 (PDT)
Received: from Heathers-MacBook-Pro.local ([2603:3023:30a:e7e0:ec87:7d39:f233:e5c7]) by with ESMTPSA id z5-v6sm2546278pfh.83.2018. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Sep 2018 17:47:31 -0700 (PDT)
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?=
References: <> <> <> <> <>
From: Heather Flanagan <>
Message-ID: <>
Date: Wed, 12 Sep 2018 17:47:29 -0700
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: multipart/alternative; boundary="------------9232DB583466C1C85DCD21C8"
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: Thu, 13 Sep 2018 00:47:37 -0000

On 9/12/18 5:25 PM, Spencer Dawkins at IETF wrote:
> I have lots of opinions about things, some of which are useful, but 
> this isn't a topic I'm smart about, so I'm mostly following the 
> discussion, to help us do the right thing, whatever that turns out to be.
> On Wed, Sep 12, 2018 at 6:19 PM Heather Flanagan (RFC Series Editor) 
> < <>> wrote:
>     On 9/12/18 7:45 AM, Paul Hoffman wrote:
>     > 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.
>     I think this is a very reasonable approach. The abstract should
>     definitely be succinct, and text explaining the relationship of
>     one RFC
>     to another (or set of others) should exist, too, but I see it
>     necessary
>     that it exists in the abstract itself. Put it in the introduction
>     or put
>     it in its own section if the relationships are complicated enough to
>     need a roadmap of some type.
> I think IESGs I've served on have tended to understand IESG statements 
> as "one size fits most". I would hope that continues for future IESGs.
> I think what you're saying here, is that we should do what is helpful 
> for most users in most cases, recognizing that if a document (say) 
> makes a non-backward-compatible change that's critical for everyone to 
> implement right now that will Update 35 RFCs, the best we can do in an 
> Abstract is say that, followed by "and if you care about protocol FOO, 
> you REALLY want to read this document".
> If I got that, you might very well be right.

Basically correct. I wouldn't list the 35 RFCs in the Abstract, and I 
would prefer it if the abstract says "This RFC updates 35 other RFCs. 
Further details are in the document itself and in the document metadata."

I think we should definitely aim for "one size fits most" and recognize 
that we can and should be flexible when the unavoidable edge case shows up.