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

Abdussalam Baryun <abdussalambaryun@gmail.com> Fri, 14 September 2018 02:42 UTC

Return-Path: <abdussalambaryun@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 81FE6130EA6 for <ietf@ietfa.amsl.com>; Thu, 13 Sep 2018 19:42:42 -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, HTML_MESSAGE=0.001, 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 XbGxNK438sn1 for <ietf@ietfa.amsl.com>; Thu, 13 Sep 2018 19:42:40 -0700 (PDT)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 5FFF9130DFA for <ietf@ietf.org>; Thu, 13 Sep 2018 19:42:40 -0700 (PDT)
Received: by mail-ot1-x32d.google.com with SMTP id v44-v6so3212539ote.13 for <ietf@ietf.org>; Thu, 13 Sep 2018 19:42:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=wrALfwZ7oECcSQsMeMmU75IVjXLKlzmJdPhkqUYtB00=; b=FeH5ZdHvnoAbyVpGH77Gy7hQD+lzehFHPVYoEKeMlv5AIFQrDzYZVSG0ZvSo73pYgW 7m4cnUkHYWQPwLDFyU7YseLG0sCDFRj+vwC41Ve0DtDdnYHbqz6wj69sr5wSQZcI1KmR SlwnkJZsrnJHcOI9PYUodzMjb8wXy9965BcQzth4Ad5vNGScpmXoMp5qHfWjn0hDvS6P sMSqoG37v4m4Nqqm499qGzgsqCjQ6T1vx/DStt+axfbXT1K+FbMS47HmV3NWVieS6z4T 6sUnlN2gU2qM0s86YNu5An4fDnsOOcS0f4oQd7QaNOJ7jMfjWZSXa6DR+FziKJGnhIZA JKuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=wrALfwZ7oECcSQsMeMmU75IVjXLKlzmJdPhkqUYtB00=; b=dBqYMSDVanMCRFLKThFeVj+l9MQSZXGVWuEQOLqnxZ6zBqENUd4vWu0Ta1rxslgFD8 qvZpWuWe/0zGyN/qnqg0rwNGhmFn7H7eiLVX+DAfP7b8WFVvAb4VOvBpR3PkxqRlwEGD 9WDaWkSvmF2uVKjp7KgIPNXaFfw9UbGc/LssuK0yhZjDDLYTT3xiWiDLJRoq8IlbC1Nv Nh0wQpRnf0tkSDT11xpMd7hPrnYGb85vB6ZsHl5cnawCZ/iIn/yUdEnIqcM4QdA/rSKG tmGeetcH6RI4itOGi7DQVskiTbvvSsAXFEDsbUoxJWo48oQXcT8yCJ45+6Cifx2Q9wAw ++hA==
X-Gm-Message-State: APzg51AbaLTrTZM6flTw8c1BanGDWZzYAd8J9cNku47Dcarnv/+qYXG9 adEgLLuXI5BjLKDI1KXxDvSic7WU0xSes1yPsAfNqU98
X-Google-Smtp-Source: ANB0VdZxpteXhVdFJY/2cCscs72LbCtL/BEVQcyMRo1Ot/3aY6CzD9uWwvNJSNr6lci7w/pOGleng1n8++TcV7JDatQ=
X-Received: by 2002:a9d:892:: with SMTP id 18-v6mr3261435otf.269.1536892959580; Thu, 13 Sep 2018 19:42:39 -0700 (PDT)
MIME-Version: 1.0
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
Date: Fri, 14 Sep 2018 04:42:19 +0200
Message-ID: <CADnDZ8_-xcwiHUbRVVq3BDP08Yb7E1d1GuwSLxnSGnstSP9P5A@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: Ben Campbell <ben@nostrum.com>
Cc: ietf <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e9e7250575cbc67a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/I2OrJtMBSFG9vEt0O3YpngScajw>
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: Fri, 14 Sep 2018 02:42:43 -0000

I agree.

I think IETF has many confused documents/RFCs for the world readers
(specially students), but still not willing to update IETF
methods to reducing such confusion (kind of old method style still in
force).

I want to add that IETF needs to consider that each update RFC doc needs to
have a number related to the updated document RFC. It is strange to have
RFC updates with different RFC numbers unrelated. Clarifying the
relationship between docs is important, and is easier by simple
numbering, especially that RFC updates is most likely to occur per author
or per WG and per future.

I prefer the update doc to have the same title of original RFC in addition
to the updated issue/section.

I think author's update docs per RFC should not be many docs but few (not
more than 3), because many updates makes confusions and separates issues
that can make many errors/misuse for the RFC users.

> On Sep 11, 2018, at 11:55, Ben Campbell <ben at 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 purpose statement section should make all update protocol things and
info clear

AB