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

Bob Hinden <bob.hinden@gmail.com> Tue, 11 September 2018 18:31 UTC

Return-Path: <bob.hinden@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 EEE5213111A; Tue, 11 Sep 2018 11:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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 tN206up_8N5O; Tue, 11 Sep 2018 11:31:32 -0700 (PDT)
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 B4DE213113B; Tue, 11 Sep 2018 11:31:32 -0700 (PDT)
Received: by mail-pg1-x536.google.com with SMTP id d1-v6so12689437pgo.3; Tue, 11 Sep 2018 11:31:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mnzxjBhmpnpBBe01vCF/pNCLv14EIszIW/ert1HwZFc=; b=DJtS+9nob4hElWqtOT5N8lt5x4SIX4jNfMVmmvQibQcoGsxGojyBImbt84aVy28ePl TRpxlfZSYiynrZ54l8ajoYs4uEjcNxhVkxoCatKN3E5NdyiY+Uu3QgE8hhNt2SYY9y2Q oH0R0wV8abrME8dkP3u5wZSQYdFZmq9Lc9hKNnQ8b2axQoi8aLXjUdnLVMBbCG5ffHw8 aphrQRrSCFnZ2DZByuU6TlSuq+h8ywNeajCImeDsXi+qfUVKtYsj5FcHF7a0r3+vB+S/ yLLC0ys9eL1+XRT9OTFvFvAGE+v5/O9w/nzcMQnN6IlBKzuoFvpN8lM9HgXSrUmpCVTK 3+Kg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mnzxjBhmpnpBBe01vCF/pNCLv14EIszIW/ert1HwZFc=; b=j4aIpLU8d9fIMAYoRSfTGuVDK4+c9KvmRMLoNvDYW36Jc9eKTWihkKlHfBJUUXGFxw KGyHjRDmLY4WyqHuOrC6XtnZHKE9J83eN1FIIToV5HbFC1fP6pTvQUWIXPLIA+j+W2UE Ou5AyxVUuYpU0yhQOOOQnI/LgHJ7IDZrp8IpoK1PIH1lipQpQw7OF9qvqahv8WnG+oSl OIQxIoeVFWJAh5ndXV3EntStXeaQbWfozuKhHfUzjMwx2bUQx3qxkNho2dkt1Ac1Xg1j nnXow6xJLbi06fsqIq2rrbuyxgtOWSJ3WQu4JcKs4kAwXoEANPtpjKBg1D/SyrW4BoLb 3gIA==
X-Gm-Message-State: APzg51Bhcg8516TjxQkkZjFsiTxSzQ7FajXqnwtSvdf50NR7EcLDq9Nw ih7Zoqmwei/CFImaQNph03A=
X-Google-Smtp-Source: ANB0VdbVsdY2yFndj1sT2up9MWrODe4TyfMJ59Kou5gd1pzhIWFFFQT/uelTrMVl/DMHYM5MFVPTIg==
X-Received: by 2002:a63:77ce:: with SMTP id s197-v6mr30262284pgc.172.1536690692216; Tue, 11 Sep 2018 11:31:32 -0700 (PDT)
Received: from [192.168.161.92] ([209.97.127.10]) by smtp.gmail.com with ESMTPSA id d81-v6sm28263389pfj.122.2018.09.11.11.31.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Sep 2018 11:31:31 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <3BAD273A-C92B-4B81-AECB-253D212ECF22@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_782E212F-EBDB-4E0B-9091-0B7E64B661D3"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Subject: =?utf-8?Q?Re=3A_Proposed_IESG_Statement_on_the_use_of_the_?= =?utf-8?Q?=E2=80=9CUpdates=E2=80=9D_header?=
Date: Tue, 11 Sep 2018 11:31:27 -0700
In-Reply-To: <59F6DED7-8D39-4206-8268-22AB6A99A876@nostrum.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, IETF <ietf@ietf.org>, IESG <iesg@ietf.org>
To: Ben Campbell <ben@nostrum.com>
References: <59F6DED7-8D39-4206-8268-22AB6A99A876@nostrum.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/LdTvc4kqXM5Z-2UTJO4nkxAg958>
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: Tue, 11 Sep 2018 18:31:42 -0000

Ben,

> On Sep 11, 2018, at 8:55 AM, Ben Campbell <ben@nostrum.com>; wrote:
> 
> Hi Everyone,
> 
> There have been several discussions lately about the use and meaning of the “Updates” header in RFCs, and the resulting “Updates”/“Updated by” relationships. The IESG is thinking about making the following statement, and solicits feedback.
> 
> Thanks!
> 
> Ben.
> --------------------------------------------
> 
> There has been considerable confusion among the IETF community about the formal meaning of the “Updates” / "Updated by" relationship in IETF stream RFCs. The “Updates” header has been historically used for number of reasons of various strength. For example, the “Updates” header may be used to indicate critical normative updates (i.e. bug fixes), optional extensions, and even “additional information”.
> 
> The IESG intends these headers to be used to inform readers of an updated RFC that they need to be aware of the RFC that updates it. The headers have no formal meaning beyond that. In particular, the headers do not, by themselves, imply a normative change to the updated RFC, nor do they, by themselves, imply that implementers must implement the updating RFC to continue to comply with the updated one.
> 
> 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 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.   I think the update text in Abstract should be limited to a few sentences and that the IESG statement include something to that effect.

> 
> The importance of including an “Updates” header depends on the nature of the update. Normative updates that do not use a known extension point should always include an “Updates” header. Extensions that do use known extension points do not typically need to include the “Updates” header, but may in cases where it’s important to make the extension known to readers of the original RFC. Other uses of “Updates” may be appropriate when it’s important for readers to know about them; for example a new RFC may expand security or operational considerations in a way that is not normative, but still important.
> 
> RFCs that fully replace other RFCs should typically use the “Obsoletes” header rather than the “Updates” header. The “Updates” header should be used to flag updates to published RFCs; it is not appropriate to “Update” an Internet-Draft.

While on the general topic of “Updates”.   Having done the process that resulted in RFC8200 that included incorporating the updates for RFC2460, it’s also important that updating RFCs are very clear what the actual change is.  This is important both for someone doing a BIS document, and for implementations understanding what the changes are.   It can be quite confusing when there a multiple updates to a single RFC.

Thanks,
Bob