Re: [rfc-i] draft-kuehlewind-update-tag/

Mirja Kuehlewind <> Fri, 27 March 2020 17:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6327E3A0F65 for <>; Fri, 27 Mar 2020 10:21:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id idSoedjw6rJR for <>; Fri, 27 Mar 2020 10:21:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 45FE43A0F3F for <>; Fri, 27 Mar 2020 10:21:21 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id F1455F4071F; Fri, 27 Mar 2020 10:21:07 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59A6FF4071F for <>; Fri, 27 Mar 2020 10:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vG22D12nnddA for <>; Fri, 27 Mar 2020 10:21:02 -0700 (PDT)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) by (Postfix) with ESMTPS id 9CC2EF4071E for <>; Fri, 27 Mar 2020 10:21:02 -0700 (PDT)
Received: from ([2003:de:e723:9a00:95ba:744f:9d24:18f2]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jHsfQ-0005D7-7c; Fri, 27 Mar 2020 18:21:12 +0100
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <>
In-Reply-To: <>
Date: Fri, 27 Mar 2020 18:21:11 +0100
Message-Id: <>
References: <> <> <> <> <> <> <> <29786.1585242645@localhost> <>
To: "" <>
X-Mailer: Apple Mail (2.3445.104.11)
X-HE-SMSGID: 1jHsfQ-0005D7-7c
Subject: Re: [rfc-i] draft-kuehlewind-update-tag/
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: "rfc-interest" <>

Hi all,

Having an IESG agreement to “give up” and not have further discussion about this could probably improve the situation but I don’t think it would make all of the time spent on discussions and explanations go away entirely because the confusion remains.

In my time as AD I would sometimes put a comment in my ballot saying something like “maybe this document should up RFCXXX” just because I thought that would be inline with other documents that have used the update tag and as a minor attempt to increase maybe consistency. The intention was only to make sure the authors have considered it. I usually got two kind of replies: either “yes, we didn’t know what to do and are happy to do whatever the IESG recommends” or alternatively a very strong opinion that this was extensively considered by the group and the way it is proposed is the only right way to handle it. Both replies are problematic as the first one is a request for guidance and the second one would warrants some clarification that (while it’s fine that every groups decides about it) there is no absolute right or wrong here and different groups treat this differently. So my assumption is that even if the IESG doesn't “provoke” that discussion it will not go away.

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).

We did discuss “just” defining the updates tag but based on the list feedback and various different uses and strong feeling about the use of it, I think that would just upset a lot of people, so we decided for defining new tag. I think the current ongoing discussion on the list again show that many people believe the know exactly what the updates tag means while other people have a similar strong feeling about a different meaning of it. Having that said we are of course open to alternative proposals or changes to the current proposal!



> On 27. Mar 2020, at 14:10, Alissa Cooper <> wrote:
> (wearing no hats, personal opinion only)
>> On Mar 26, 2020, at 1:10 PM, Michael Richardson <> wrote:
>> (We could have a moritorium on the IESG talking about Updates.)
> Fully support this. The main reason the IESG talks about this a lot is because ADs question the use of the tag. In the absence of mutable documents and since we tried multiple times to see if there could be clarity in the community about what “updates” means and failed, we could just accept that it’s an unclear tag and stop discussing it. We could even document the moratorium in an IESG statement.
> Alissa
>> --
>> Michael Richardson <>ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>> _______________________________________________
>> rfc-interest mailing list
> _______________________________________________
> rfc-interest mailing list

rfc-interest mailing list