Re: [rfc-i] Feedback solicited: Update tags draft

Mirja Kuehlewind <> Mon, 09 March 2020 17:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 833473A1476 for <>; Mon, 9 Mar 2020 10:42:40 -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 utwpXmwJAzlA for <>; Mon, 9 Mar 2020 10:42:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AD4EF3A145F for <>; Mon, 9 Mar 2020 10:42:38 -0700 (PDT)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 4B4FBF40719; Mon, 9 Mar 2020 10:42:36 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E6BC6F40719 for <>; Mon, 9 Mar 2020 10:42:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8EEY5oaV3CVA for <>; Mon, 9 Mar 2020 10:42:32 -0700 (PDT)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) by (Postfix) with ESMTPS id 4F11DF40704 for <>; Mon, 9 Mar 2020 10:42:32 -0700 (PDT)
Received: from ([2003:de:e723:9a00:3482:4523:72c2:a10c]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jBMQC-0007Bt-KC; Mon, 09 Mar 2020 18:42:32 +0100
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <>
In-Reply-To: <>
Date: Mon, 9 Mar 2020 18:42:31 +0100
Message-Id: <>
References: <> <> <> <> <>
To: Eric Rescorla <>
X-Mailer: Apple Mail (2.3445.104.11)
Subject: Re: [rfc-i] Feedback solicited: Update tags draft
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: <>, <>
Cc: RFC Interest <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: "rfc-interest" <>

Hi Ekr,

We just submitted a new version and I tried to add a note about conformance, however, not sure we can say much in this draft. Please see also below for further comments!

> On 29. Feb 2020, at 14:50, Eric Rescorla <> wrote:
> On Sat, Feb 29, 2020 at 12:48 AM Suresh Krishnan <> wrote:
> Hi Ekr,
> > On Feb 28, 2020, at 9:23 AM, Eric Rescorla <> wrote:
> > 
> > At present, I am not in favor of these changes.
> > 
> > We already spend quite a bit of time debating which tags should apply when compared to the (IMO marginal) value of these tags, and this seems likely to make that worse. 
> > 
> > The "amended" tag in particular seems like a workaround for our refusal to simply update RFCs when they are wrong. The first rule of holes to stop digging.
> The option to bis the RFCs will still exist and the IESG can still guide people to do that. The goal of the Amended tag is to point implementers to other RFCs that are mandatory to implement. Right now Updates is being used both for optional extensions as well as for mandatory changes and the goal is to disambiguate this.
> I'm not talking about -bising the RFC. I'm talking about re-publishing
> with the same RFC #.

I think that is really a broader topic for discussion and will probably require a whole bunch of changes to how we work and publish. The IESG started some discussion about living documents and I think there are many open questions. But I really think this is mostly an independent discussion to what is proposed in the draft.

> More generally, I don't really understand what you think "mandatory"
> means. 
> Consider two cases:
> 1. We publish an RFC X with a clear mistake. For instance, it allocates
>    two code points, A and B, and then in the text it says A=1 and
>    B=2 but in the IANA considerations it says A=1, B=1
> 2. We publish an RFC X with an algorithm we later determine to be bad.
>    For instance it says to use a parameter 2 but we later determine
>    that 2 is bad and 3 would be better.
> In the former case, I would argue that the RFC correctly read had the
> code points A=1 B=2 and thus in order to be conformant with RFC X, you
> need to adopt B=2.

Yes and I think these things are often rather errata.
> However, what would you say in the latter case?  Older implementations
> continue to be conformant with RFC X, but just not with RFC Y, which
> you publish later. So, what does "mandatory" mean in this case? The
> problem here, as usual, is the failure to have some way to refer to
> the concept of the protocol rather than the concept of the RFC.

This part I tried to clarify in the draft. Extending/amending does not change the existing RFC. That means if someone's implementation conform to that RFC, it still does so even when a new amending RFC is published. However, with amend there is now an explicit recommendation that implementations should also update to confirm to the new RFC. 

The other option would be to bis a spec and obsolete the old one. However, even if an RFC is obsoleted, old implementation that conform to that RFC will still only conform to that RFC and not magically change. Similar as proposed for “Amends”, there however is a stronger expectation that those implementations need to change. 


> -Ekr
> _______________________________________________
> rfc-interest mailing list

rfc-interest mailing list