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

Mirja Kuehlewind ietf at kuehlewind.net
Fri Mar 27 10:21:11 PDT 2020

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!


[1] https://mailarchive.ietf.org/arch/msg/ietf/-1u_1-peHKAmUDuLyGAJYu0fPCE/

> On 27. Mar 2020, at 14:10, Alissa Cooper <alissa at cooperw.in> wrote:
> (wearing no hats, personal opinion only)
>> On Mar 26, 2020, at 1:10 PM, Michael Richardson <mcr+ietf at sandelman.ca> 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 <mcr+IETF at sandelman.ca>, Sandelman Software Works
>> -= IPv6 IoT consulting =-
>> _______________________________________________
>> rfc-interest mailing list
>> rfc-interest at rfc-editor.org
>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest

More information about the rfc-interest mailing list