[rfc-i] Updates solution that you object to (was Re: draft-kuehlewind-update-tag/)

Michael Richardson <mcr+ietf@sandelman.ca> Sun, 29 March 2020 21:33 UTC

Return-Path: <rfc-interest-bounces@rfc-editor.org>
X-Original-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Delivered-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AC2443A0BFD for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Sun, 29 Mar 2020 14:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.75
X-Spam-Status: No, score=-0.75 tagged_above=-999 required=5 tests=[HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id SDm4ciE-eDHN for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Sun, 29 Mar 2020 14:33:53 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A45C3A0BF9 for <rfc-interest-archive-SieQuei0be@ietf.org>; Sun, 29 Mar 2020 14:33:53 -0700 (PDT)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id 5413AF4073A; Sun, 29 Mar 2020 14:33:51 -0700 (PDT)
X-Original-To: rfc-interest@rfc-editor.org
Delivered-To: rfc-interest@rfc-editor.org
Received: from localhost (localhost []) by rfc-editor.org (Postfix) with ESMTP id 27404F4073A for <rfc-interest@rfc-editor.org>; Sun, 29 Mar 2020 14:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
Received: from rfc-editor.org ([]) by localhost (rfcpa.amsl.com []) (amavisd-new, port 10024) with ESMTP id RwBJEQYnbwAJ for <rfc-interest@rfc-editor.org>; Sun, 29 Mar 2020 14:33:48 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by rfc-editor.org (Postfix) with ESMTPS id C657CF40739 for <rfc-interest@rfc-editor.org>; Sun, 29 Mar 2020 14:33:47 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca []) by tuna.sandelman.ca (Postfix) with ESMTP id A75103897D for <rfc-interest@rfc-editor.org>; Sun, 29 Mar 2020 17:32:09 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 890A6B98 for <rfc-interest@rfc-editor.org>; Sun, 29 Mar 2020 17:33:37 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "rfc-interest\@rfc-editor.org" <rfc-interest@rfc-editor.org>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Date: Sun, 29 Mar 2020 17:33:37 -0400
Message-ID: <16383.1585517617@localhost>
Subject: [rfc-i] Updates solution that you object to (was Re: draft-kuehlewind-update-tag/)
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1361222462163732026=="
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: "rfc-interest" <rfc-interest-bounces@rfc-editor.org>

Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
    > I mentioned this briefly at the beginning of my presentation in
    > gendispatch but to provide more background: The IESG already tried to
    > address the problem by proposing an IESG statement to clarify that the
    > updates tag merely provides a link but otherwise brings no defined
    > obligations with it, see [1]. The feedback we got from the community at
    > that time was that they would prefer a clear definition. So Suresh and
    > I took this up and are proposing this as members of the community (of
    > course with the background that we are well aware of any IESG
    > discussions related to this topic that happen in the last 4 years).

Thank you again for taking this on.

We have had a number of strong opinions about what we should do.

Opinions I have read proponents for:
   1) Updates is fine, keep it as is.
   2) The three tags are good.
   3) New tags are needed, but not sure if these work
   4) The three tags will just make it 3x worse
   5) I like Updates->Amends, but other two are useless
   6) Get rid of all tags, write it all up the document
      {6B) write it up in some split-up Normative Updates section}

   (Maybe there a few I have missed!)

What I haven't heard a lot of, (attempting to channel Pete and 7282):

     I can not live with option FOO (because ...)

Well. Maybe (4) above is such an expression.
I think that the community may have said it can not live with (1).

It would be good if people could recognize if they are in the rough, and work
to figure out which things they could live with.

Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

rfc-interest mailing list