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

Eric Rescorla <ekr@rtfm.com> Mon, 09 March 2020 17:45 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7703A1402 for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Mon, 9 Mar 2020 10:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3fjQzi_x40V for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Mon, 9 Mar 2020 10:45:58 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029CF3A1403 for <rfc-interest-archive-SieQuei0be@ietf.org>; Mon, 9 Mar 2020 10:45:57 -0700 (PDT)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id 98336F40704; Mon, 9 Mar 2020 10:45:55 -0700 (PDT)
X-Original-To: rfc-interest@rfc-editor.org
Delivered-To: rfc-interest@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id C4996F40704 for <rfc-interest@rfc-editor.org>; Mon, 9 Mar 2020 10:45:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
Authentication-Results: rfcpa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyfy7EN7NzPA for <rfc-interest@rfc-editor.org>; Mon, 9 Mar 2020 10:45:53 -0700 (PDT)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) by rfc-editor.org (Postfix) with ESMTPS id 15858F406D1 for <rfc-interest@rfc-editor.org>; Mon, 9 Mar 2020 10:45:53 -0700 (PDT)
Received: by mail-lj1-x235.google.com with SMTP id o10so4175910ljc.8 for <rfc-interest@rfc-editor.org>; Mon, 09 Mar 2020 10:45:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JIi0/HyMzE4SMmPVV3BTdQBV+FjyOvRa0GzzIHw8Oaw=; b=LscXFZl4Sv04V6WJIIRFep+ll3B2sXFLI9QPZlfviXNnv8NnO5/2jAaPEjXv4xQqf5 ow+qLAn96dBtDmeB/l+GgdHu7lPUGn1q/fiVhjW3YHKikUnT5YeaeWdlL8LCNYjbGktJ h5/uSws0L2VQx4pb9M1t+Qcy3LcYsxD2/hivmfcCvuPl4eh2LmFg61cjZSZjR24qGXkg Cw6oh4Uo8a/hwFhcNWv6WA8oMiXmekUIKF/LxILfHv7w65jdH35GB5s4HwbyidREJrln da+zg2Tf1C9ioMi08ZLrBnzFrCOvoek5ENDKbN6tOimlEW+Ny3veo/uquzxnWoCXHmfK +6tg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JIi0/HyMzE4SMmPVV3BTdQBV+FjyOvRa0GzzIHw8Oaw=; b=jp5rMgM/6yv+V/joM7Vjemas9DX92YkK8snKd2jp8FF1kC5N6fxGTU/5iGyQzwUea7 khsBFCEiS4G60ITgzINZmjEXgYZ3/G+77qhRI/TDe6KyB2Qy4Akilt/SiLAuQnYI4AFA JoBRRufqnbqZX6MlJWxg3GNXYg4O4XOimoSkEFw+3GTZbkGXD+IzB0iXdyFJRiTggaCr QylDV1wXz2iQnIdaitQxiu/+Ylv9/5tq2Kn9UXc1krPpnC3rIXX3ElUS2XqQSlFejNND 1EryE/WKgLD8fUOi5sQArdCMbNuGzgLOnkqfJk/2JqUOU55UUI28VGzQ3ehmQCvHDnic zprQ==
X-Gm-Message-State: ANhLgQ233aZRJuRUC+nl7upbW5lb2DpT+3yhWlL8ZPYNvJApzHfjqOyV ws3BXkXYC3Z/+spd4q6ngu/96ZGmtyWrw9gkr67bFg==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vtHOIrfl11JUyfFF++gHKUnvQngqfTjDIWLom33?= =?utf-8?q?D9y5R8vsyZpggfQP+ItfSZZhnX+cauETokfwkdgMtTBmJig=3D?=
X-Received: by 2002:a2e:7a0c:: with SMTP id v12mr1075310ljc.274.1583775953100; Mon, 09 Mar 2020 10:45:53 -0700 (PDT)
MIME-Version: 1.0
References: <447718E1-D2EF-41B1-94DD-AB121EAA79BB@gmail.com> <179BB23D-825A-4177-B656-1B396903C7D8@gmail.com> <CABcZeBODoQTd+fdgqpLwXWhE5P35gTN5S-3zN5+_+7Mcb4PbzQ@mail.gmail.com> <AB0B3305-FCEC-48E6-A916-B86245CD1C3E@gmail.com> <CABcZeBMCZfSxTXUj0+Kuy2QJi+vJHcPpWjydobTD4ztuzTR2rQ@mail.gmail.com> <684602E7-52DF-46B3-B6F1-3F0ACEF092F4@kuehlewind.net>
In-Reply-To: <684602E7-52DF-46B3-B6F1-3F0ACEF092F4@kuehlewind.net>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 9 Mar 2020 10:45:16 -0700
Message-ID: <CABcZeBMsFkTPMwRLKBa0T1OOBbmKfRPnaGhF=bkYaDNcWAdrdQ@mail.gmail.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>
Subject: Re: [rfc-i] Feedback solicited: Update tags draft
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>
Cc: RFC Interest <rfc-interest@rfc-editor.org>
Content-Type: multipart/mixed; boundary="===============0955745035049208629=="
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: "rfc-interest" <rfc-interest-bounces@rfc-editor.org>

On Mon, Mar 9, 2020 at 10:42 AM Mirja Kuehlewind <ietf@kuehlewind.net>
wrote:

> 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 <ekr@rtfm.com> wrote:
> >
> >
> >
> > On Sat, Feb 29, 2020 at 12:48 AM Suresh Krishnan <
> suresh.krishnan@gmail.com> wrote:
> > Hi Ekr,
> >
> > > On Feb 28, 2020, at 9:23 AM, Eric Rescorla <ekr@rtfm.com> 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.
>

I don't agree. This draft seems like a clunky fix for what is broadly the
same problem.

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

Yes.


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

These seem like extremely fine distinctions that are not going to be at all
useful in practice. I am having trouble seeing how we would meaningfully
use them to guide our implementation.

-Ekr

Mirja
>
>
>
> >
> > -Ekr
> > _______________________________________________
> > rfc-interest mailing list
> > rfc-interest@rfc-editor.org
> > https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>
>
_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest