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

Michael Richardson <> Thu, 26 March 2020 01:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B79B3A0128 for <>; Wed, 25 Mar 2020 18:52:06 -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 w67h-BmC7Xdm for <>; Wed, 25 Mar 2020 18:52:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC2D03A0778 for <>; Wed, 25 Mar 2020 18:51:55 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 96233F40722; Wed, 25 Mar 2020 18:51:39 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 10883F40722 for <>; Wed, 25 Mar 2020 18:51:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZgxBNOiJ1Sdd for <>; Wed, 25 Mar 2020 18:51:33 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by (Postfix) with ESMTPS id 42CBEF40712 for <>; Wed, 25 Mar 2020 18:51:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 40F4638982 for <>; Wed, 25 Mar 2020 21:50:15 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id D7011547 for <>; Wed, 25 Mar 2020 21:51:39 -0400 (EDT)
From: Michael Richardson <>
In-Reply-To: <>
References: <>
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: Wed, 25 Mar 2020 21:51:39 -0400
Message-ID: <28204.1585187499@localhost>
Subject: Re: [rfc-i] draft-kuehlewind-update-tag comments
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: multipart/mixed; boundary="===============4690355825061419760=="
Sender: "rfc-interest" <>

Toerless Eckert <> wrote:
    > I like to solve the problem. I am not sure the proposed solution is
    > sufficient though.

    > On the nitpicking style, i am not sure that the distinction of
    > New MUST -> Amends New "optional" is a good way to define
    > the distinctions:

    > If i was an operator, i would primarily like to understand the
    > interoperability effects. We the new document be expected to
    > interoperate in all circumstances with the old version RFC ?
    > Security Amendmends certainly will the need option to kill
    > backward compatibility (old RFC had a now broken security scheme).

That's a place where I didn't know if Amends really meant "fixes", and if we
wanted to mix mandatory fixes in with things which just clarify things.

    > I would feel a lot easier to conclude what would need to be
    > done if there was a collection of different example "use cases",
    > and challenge the community to come up with new "use cases" where
    > the proposed solution does not work well enough.

I think that might work.
That's where the review of uses might be good.

    > I "feel" that it would be better not to try to solve our issues
    > nly with as few as possible tags, but also ponder what a good
    > amendment/extensions text in an RFC should look like.
    > E.g.: separate section summarising "Changes" over the prior
    > RFC is IMHO a good approach.

    > "This rfc replaces the following text in prior RFC with the
    > text outlined in section xx of this rfc. This impacts
    > interoperability as follows".

I have some additional thoughts here.
A number of people in the jabber suggested the same thing.

I want to point out that we already have a forward reference meta-data in the
DT, because documents which reference a document create that backward
reference, and we simply invert the reference.

What I think that we might need is annotation in the normative XML that
indicates that this is essentially an Updates.
I think they need to be normative, but maybe we want to split the normative
into "background reading", and "updates" section.
Not all normative references should cause forward references.

This puts all the decisions back into the WG, provides clear way to do the
text, etc.  Maybe we want a clear section header for this.
This might take a year or so to sort out and become BCP.


My suggestion for the IESG is that we just stop using Updates.
We can't argue of things then.

My next suggestion, regardless of what we above, that we allow WGs to go back
an annotate documents as to what kind of update they do.
Maybe this document is the right set of names, maybe some new ones would emerge.
How we store this information is open.  It could be posted as errata, or...

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

rfc-interest mailing list