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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Thu, 13 September 2018 00:25 UTC

Return-Path: <spencerdawkins.ietf@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 6A183130ED4 for <ietf@ietfa.amsl.com>; Wed, 12 Sep 2018 17:25:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: 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 JJb1l7KmnNO4 for <ietf@ietfa.amsl.com>; Wed, 12 Sep 2018 17:25:52 -0700 (PDT)
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (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 29F3A129385 for <ietf@ietf.org>; Wed, 12 Sep 2018 17:25:52 -0700 (PDT)
Received: by mail-yb1-xb2c.google.com with SMTP id j8-v6so2556871ybg.9 for <ietf@ietf.org>; Wed, 12 Sep 2018 17:25:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r3o4PBTz/oCsLxA64dMGAT3f4TI6iGi5AHC8Zu+JV0U=; b=R74xCN75VUv9g12osXN7T3B4/5AAFwc+p+l87bGlVhzKncH/P92JQKcYtY4dIo8IEb QePHHC3fc72Abp5cRk5lXabnlhFeKbsxzodVtJXmZ8E/iVoNDRkH+VAix0foPIlnXS2K rHYu/QjYBGn0MdVSYYE/giEt9UH/BPIRF7/otMsT1lrJwo0iNUkAPcF0lDgQCtkT3WAt yBVjY3xyfDCoDAvF5NKARJYtx8/qCy2iVuk1gNIlL/l+PZoDPts+jxORvKPVJcb9aO5Y S8McAOf6ll9NJxPir5nxo0STthODAk1tfgxjTU+HgN5I+S2eECjAL4LcWiItDW4R2V+W VVdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r3o4PBTz/oCsLxA64dMGAT3f4TI6iGi5AHC8Zu+JV0U=; b=r0dIyop4FY+xzpOgg+qUpNRZsqr2r8NZz/EUdItRV3rRpqkDiIlJZoYDMzer864r1F Fg1QOLsbQZjWFsO9q/HWVGdKKYf1PSaQniQeimG89tw0Ly1P4Jp/PsKAYlbcR51r7o8c AX6FM7OUJINchEEjWAV86C1bx4Z+QYYs2x5ltYQN+K8K/OgP25kaPqz9CvSQE1xX/T91 abAFGXi9fCnW0LbwM/LL39Zvq9YKybJiSZhp9XR5xkanLCAdCa+dU3bIAX+EA2ZrkDjL KbZ2gN5O5RBf4TVhaSAA5mgtLnOo/VzPlL3sjH47FRgClAV9AIqvqcNE52ZJYOCTRCdx gh5A==
X-Gm-Message-State: APzg51Bo9VCQUz8GDgV91Wq629pefMXFgTpIBtaiWoBYHH3ibiKwQgoF nP1Cjy7iq9Zu0bYUPL61C+zJTgnVXEjPFJCLl44=
X-Google-Smtp-Source: ANB0Vda0f08q5zp2yPWwvA2sMhtt3JYNvRGjr76JbSwkHCdG1M4z6tcQqtGzqa6jq81Df5GRRZILP0ErGTdtaR7WZCU=
X-Received: by 2002:a25:cc4:: with SMTP id 187-v6mr2224008ybm.490.1536798351272; Wed, 12 Sep 2018 17:25:51 -0700 (PDT)
MIME-Version: 1.0
References: <59F6DED7-8D39-4206-8268-22AB6A99A876@nostrum.com> <8DA3AA49-BB06-4DA6-A028-F487FC9822EB@sn3rd.com> <AFE1600A-7883-4CD6-BD6A-232E12514123@vpnc.org> <f3d09ca0-bade-186d-2441-39215f387403@rfc-editor.org>
In-Reply-To: <f3d09ca0-bade-186d-2441-39215f387403@rfc-editor.org>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 12 Sep 2018 19:25:37 -0500
Message-ID: <CAKKJt-dW04hS_TDuG-7GVfOaDUmJ7b4BSWA4XN1V7oOW2=i4Uw@mail.gmail.com>
Subject: =?UTF-8?Q?Re=3A_Proposed_IESG_Statement_on_the_use_of_the_=E2=80=9CUpd?= =?UTF-8?Q?ates=E2=80=9D_header?=
To: "Heather Flanagan (RFC Series Editor)" <rse@rfc-editor.org>
Cc: IETF list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d1ae9b0575b5bfb1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/AvCCjnkHwLokzkTSoBGy_paYh2U>
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: Thu, 13 Sep 2018 00:25:55 -0000

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) <
rse@rfc-editor.org>; 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.

Spencer


> -Heather
>
>